actually looks like the table on the webpage and is entertainingly
smaller, easier to read, and easier to edit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202371 91177308-0d34-0410-b5e6-96231b3b80d8
getting started guide.
Some highlights:
- I heard there was this Clang compiler that you could use for your
host compiler. Not sure though.
- We no longer have a GCC frontend with weird build restrictions.
- Windows is doing a bit better than partially supported.
- We nuked everything to do with itanium.
- SPUs? Really?
- Xcode 2.5 and gcc 4.0.1 are really not a concern -- they don't work.
- OMG, we actually tried building LLVM on Alpha? Really?
- PowerPC works pretty well these days.
There is still a lot of stuff here I'm pretty dubious about, but I nuked
most of what was actively misleading, out of date, or patently wrong.
Some of it (mingw stuff especially) isn't really lacking, its just that
the comments here were actively wrong. Hopefully folks that know those
platforms can add back correct / modern information.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202370 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Fixes an issue where a test attempts to use -mcpu=x86-64 on non-X86-64 targets.
This triggers an assertion in the MIPS backend since it doesn't know what ABI to
use by default for unrecognized processors.
CC: llvm-commits, rafael
Differential Revision: http://llvm-reviews.chandlerc.com/D2877
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202369 91177308-0d34-0410-b5e6-96231b3b80d8
any ranges - this includes CU ranges where we were previously emitting an
end list marker even if we didn't have a list.
Testcase includes a test for line table only code emission as the problem
was noticed while writing this test.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202357 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r202283, because when we use GuardMalloc the test will fail
due to additional output to std err.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202341 91177308-0d34-0410-b5e6-96231b3b80d8
If the SI_KILL operand is constant, we can either clear the exec mask if
the operand is negative, or do nothing otherwise.
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202337 91177308-0d34-0410-b5e6-96231b3b80d8
any ranges to the list of ranges for the CU as we don't want to emit
them anyway. This ensures that we will still emit ranges if we have
a compile unit compiled with only line tables and one compiled with
full debug info requested (we'll emit for the one with full debug info).
Update testcase metadata accordingly to continue emitting ranges.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202333 91177308-0d34-0410-b5e6-96231b3b80d8
and update everything accordingly. This can be used to conditionalize
the amount of output in the backend based on the amount of debug
requested/metadata emission scheme by a front end (e.g. clang).
Paired with a commit to clang.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202332 91177308-0d34-0410-b5e6-96231b3b80d8
This handles pathological cases in which we see 2x increase in spill
code for large blocks (~50k instructions). I don't have a unit test
for this behavior.
Fixes rdar://16072279.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202304 91177308-0d34-0410-b5e6-96231b3b80d8
Using @executable_path/../lib matches what we have on Makefiles and works
with older versions of OS X too.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202302 91177308-0d34-0410-b5e6-96231b3b80d8
The current approach to lower a vsetult is to flip the sign bit of the
operands, swap the operands and then use a (signed) pcmpgt. psubus (unsigned
saturating subtract) can be used to emulate a vsetult more efficiently:
+ case ISD::SETULT: {
+ // If the comparison is against a constant we can turn this into a
+ // setule. With psubus, setule does not require a swap. This is
+ // beneficial because the constant in the register is no longer
+ // destructed as the destination so it can be hoisted out of a loop.
I also enable lowering via psubus in a few other cases where it's clearly
beneficial: setule and setuge if minu/maxu cannot be used.
rdar://problem/14338765
Patch by Adam Nemet <anemet@apple.com>.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202301 91177308-0d34-0410-b5e6-96231b3b80d8
The aggressive anti-dependency breaker scans instructions, bottom-up, within the
scheduling region in order to find opportunities where register renaming can
be used to break anti-dependencies.
Unfortunately, the aggressive anti-dep breaker was treating a register definition
as defining all of that register's aliases (including super registers). This behavior
is incorrect when the super register is live and there are other definitions of
subregisters of the super register.
For example, given the following sequence:
%CR2EQ<def> = CROR %CR3UN, %CR3UN<kill>
%CR2GT<def> = IMPLICIT_DEF
%X4<def> = MFOCRF8 %CR2
the analysis of the first subregister definition would work as expected:
Anti: %CR2GT<def> = IMPLICIT_DEF
Def Groups: CR2GT=g194->g0(via CR2)
Antidep reg: CR2GT (zero group)
Use Groups:
but the analysis of the second one would not:
Anti: %CR2EQ<def> = CROR %CR3UN, %CR3UN<kill>
Def Groups: CR2EQ=g195
Antidep reg: CR2EQ
Rename Candidates for Group g195: ...
because, when processing the %CR2GT<def>, we'd mark all super registers of
%CR2GT (%CR2 in this case) as defined. As a result, when processing
%CR2EQ<def>, %CR2 no longer appears to be live, and %CR2EQ<def>'s group is not
%unioned with the %CR2 group.
I don't have an in-tree test case for this yet (and even if I did, I don't have
a small one).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202294 91177308-0d34-0410-b5e6-96231b3b80d8
COFF object files with 0 as string table size are currently rejected. This
prevents us from reading object files written by tools like cvtres that
violate the PECOFF spec and write 0 instead of 4 for the size of an empty
string table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202292 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes spurious warnings in llvm-link about the datalayout not matching.
Thanks to Zalman Stern for reporting the bug!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202276 91177308-0d34-0410-b5e6-96231b3b80d8
We don't have any test with more than 6 address spaces, so a DenseMap is
probably not the correct answer.
An unsorted array would also be OK, but we have to sort it for printing anyway.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202275 91177308-0d34-0410-b5e6-96231b3b80d8
This includes instructions with aggregate operands (insert/extract), instructions with vector operands (insert/extract/shuffle), binary arithmetic and bitwise instructions, conversion instructions and terminators.
Work was done by lama.saba@intel.com.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202262 91177308-0d34-0410-b5e6-96231b3b80d8
The table argument is always 128-bit (and interpreted as <16 x i8>) so the
extra specifier for it is just clutter.
No user-visible behaviour change, so no tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202258 91177308-0d34-0410-b5e6-96231b3b80d8
