| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
It was causing horrible failures on some build-bots.
llvm-svn: 205105
|
|
|
|
|
|
|
|
|
| |
When LLVM is not built with zlib, nocompression.s will test
for the error message. But this test case will cause breakage
because the exit code is non-zero. This commit fix this issue
by adding "not" to the command.
llvm-svn: 205102
|
|
|
|
|
|
|
|
| |
The vector divide and sqrt instructions have high latencies, and the scalar
comparisons are like all of the others. On the P7, permutations take an extra
cycle over purely-simple vector ops.
llvm-svn: 205096
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Issue subject: Crash using integrated assembler with immediate arithmetic
Fix description:
Expressions like 'cmp r0, #(l1 - l2) >> 3' could not be evaluated on asm parsing stage,
since it is impossible to resolve labels on this stage. In the end of stage we still have
expression (MCExpr).
Then, when we want to encode it, we expect it to be an immediate, but it still an expression.
Patch introduces a Fixup (MCFixup instance), that is processed after main encoding stage.
llvm-svn: 205094
|
|
|
|
|
|
| |
Another existing bot failure so no tests.
llvm-svn: 205093
|
|
|
|
|
|
| |
Existing tests were failing.
llvm-svn: 205092
|
|
|
|
|
|
|
|
|
|
|
| |
no assert at all. ;] Some of these should probably be switched to
llvm_unreachable, but I didn't want to perturb the behavior in this
patch.
Found by -Wstring-conversion, which I'll try to turn on in CMake builds
at least as it is finding useful things.
llvm-svn: 205091
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a second implementation of the AArch64 architecture to LLVM,
accessible in parallel via the "arm64" triple. The plan over the
coming weeks & months is to merge the two into a single backend,
during which time thorough code review should naturally occur.
Everything will be easier with the target in-tree though, hence this
commit.
llvm-svn: 205090
|
|
|
|
|
|
|
| |
ARM64 ended up reaching odder parts of TableGen alias generation than
current backends and caused a segfault.
llvm-svn: 205089
|
|
|
|
|
|
| |
Some exotic types didn't know how to handle FROUND, which ARM64 uses.
llvm-svn: 205088
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM64 has compact-unwind information, but doesn't necessarily want to
emit .eh_frame directives as well. This teaches MC about such a
situation so that it will skip .eh_frame info when compact unwind has
been successfully produced.
For functions incompatible with compact unwind, the normal information
is still written.
llvm-svn: 205087
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Given IR like:
%bit = and %val, #imm-with-1-bit-set
%tst = icmp %bit, 0
br i1 %tst, label %true, label %false
some targets can emit just a single instruction (tbz/tbnz in the
AArch64 case). However, with ISel acting at the basic-block level, all
three instructions need to be together for this to be possible.
This adds another transformation to CodeGenPrep to expose these
opportunities, if targets opt in via the hook.
llvm-svn: 205086
|
|
|
|
|
|
|
|
| |
This is principally to allow neater mapping of fixups to relocations
in ARM64 ELF. Without this, there isn't enough information available
to GetRelocType, leading to many more fixup_arm64_... enumerators.
llvm-svn: 205085
|
|
|
|
|
|
|
|
| |
Another part of the ARM64 backend (so tests will be following soon).
This is currently used by the linker to relax adrp/ldr pairs into nops
where possible, though could well be more broadly applicable.
llvm-svn: 205084
|
|
|
|
|
|
| |
This was accidentally omitted from r205081.
llvm-svn: 205083
|
|
|
|
|
|
|
|
|
| |
The upcoming ARM64 backend doesn't have section-relative relocations,
so we give each section its own symbol to provide this functionality.
Of course, it doesn't need to appear in the final executable, so
linker-private is the best kind for this purpose.
llvm-svn: 205081
|
|
|
|
|
|
|
|
| |
ARM64 for iOS is going to want to emit these symbols in a
linker-private style for efficiency, but other targets probably don't
want that behaviour.
llvm-svn: 205080
|
|
|
|
|
|
|
|
|
|
| |
This is like the LLVMMatchType, except the verifier checks that the
second argument is a vector with the same base type and half the
number of elements.
This will be used by the ARM64 backend.
llvm-svn: 205079
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I started trying to fix a small issue, but this code has seen a small fix too
many.
The old code was fairly convoluted. Some of the issues it had:
* It failed to check if a symbol difference was in the some section when
converting a relocation to pcrel.
* It failed to check if the relocation was already pcrel.
* The pcrel value computation was wrong in some cases (relocation-pc.s)
* It was missing quiet a few cases where it should not convert symbol
relocations to section relocations, leaving the backends to patch it up.
* It would not propagate the fact that it had changed a relocation to pcrel,
requiring a quiet nasty work around in ARM.
* It was missing comments.
llvm-svn: 205076
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We had stored both f64 values and v2f64, etc. values in the VSX registers. This
worked, but was suboptimal because we would always spill 16-byte values even
through we almost always had scalar 8-byte values. This resulted in an
increase in stack-size use, extra memory bandwidth, etc. To fix this, I've
added 64-bit subregisters of the Altivec registers, and combined those with the
existing scalar floating-point registers to form a class of VSX scalar
floating-point registers. The ABI code has also been enhanced to use this
register class and some other necessary improvements have been made.
llvm-svn: 205075
|
|
|
|
|
|
|
| |
Canonicalise the default triple that is used on Windows. This should hopefully
fix the MSVC buildbots.
llvm-svn: 205070
|
|
|
|
|
|
|
|
|
| |
Emit 32-bit register names instead of 64-bit register names if the target does
not have 64-bit general purpose registers.
<rdar://problem/14653996>
llvm-svn: 205067
|
|
|
|
|
|
|
|
| |
Turns out debug_frame does use multiple fragments, so it doesn't
compress correctly with the current approach. Disable compressing it for
now while I figure out what's the best solution for it.
llvm-svn: 205059
|
|
|
|
|
|
|
|
|
|
| |
WinCOFF cannot form PC relative relocations to support absolute
MCValues. We should reenable this once WinCOFF supports emission of
IMAGE_REL_I386_REL32 relocations.
This fixes PR19272.
llvm-svn: 205058
|
|
|
|
| |
llvm-svn: 205053
|
|
|
|
|
|
|
|
|
|
| |
This is a bit of a stab in the dark, since I have zlib on my machine.
Just going to bounce it off the bots & see if it sticks.
Do we have some convention for negative REQUIRES: checks? Or do I just
need to add a feature like I've done here?
llvm-svn: 205050
|
|
|
|
|
|
|
| |
Not only did I invert the indices when I wrote the code, but I also did the
same thing when I wrote the regression test. Oops.
llvm-svn: 205046
|
|
|
|
|
|
| |
Unfortunately this one fails deep inside the mips backend, so xfail it.
llvm-svn: 205042
|
|
|
|
|
|
|
|
| |
v2[fi]64 values need to be explicitly passed in VSX registers. This is because
the code in TRI that finds the minimal register class given a register and a
value type will assert if given an Altivec register and a non-Altivec type.
llvm-svn: 205041
|
|
|
|
| |
llvm-svn: 205040
|
|
|
|
| |
llvm-svn: 205039
|
|
|
|
|
|
|
|
|
| |
It was using "lc -filetype=obj" just to pass the result to
"llvm-objdupm -disassemble" and then filecheck assembly.
The CHECK-NOT would never match anyway since it was missing $.
llvm-svn: 205036
|
|
|
|
| |
llvm-svn: 205033
|
|
|
|
|
|
|
| |
This adds a new header, EndianStream.h, which supplies an adaptor for
writing endian specific data to a raw_ostream.
llvm-svn: 205032
|
|
|
|
|
|
| |
With that, convert another llc -filetype=obj test.
llvm-svn: 205031
|
|
|
|
| |
llvm-svn: 205028
|
|
|
|
| |
llvm-svn: 205027
|
|
|
|
| |
llvm-svn: 205026
|
|
|
|
|
|
|
|
|
| |
Extract element instructions that will be removed when vectorzing lower the
cost.
Patch by Arch D. Robison!
llvm-svn: 205020
|
|
|
|
|
|
| |
Patch by Arch D. Robison!
llvm-svn: 205019
|
|
|
|
|
|
| |
Patch by Arch D. Robison!
llvm-svn: 205018
|
|
|
|
|
|
|
|
|
| |
The non-SJLJ and SJLJ intrinsics are generated by the frontend and
backend respectively.
Differential Revision: http://llvm-reviews.chandlerc.com/D3010
llvm-svn: 205017
|
|
|
|
|
|
|
| |
I'll implement error handling and a negative test in both llvm-mc and
Clang soon.
llvm-svn: 205016
|
|
|
|
| |
llvm-svn: 205014
|
|
|
|
| |
llvm-svn: 205013
|
|
|
|
|
|
|
|
|
| |
This reverts commit r204912, and follow-up commit r204948.
This introduced a performance regression, and the fix is not completely
clear yet.
llvm-svn: 205010
|
|
|
|
|
|
|
|
|
| |
This reverts commit r203553, and follow-up commits r203558 and r203574.
I will follow this up on the mailinglist to do it in a way that won't
cause subtle PRE bugs.
llvm-svn: 205009
|
|
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3095
llvm-svn: 205007
|
|
|
|
|
|
|
|
| |
This was causing my llc to go into an infinite loop on
CodeGen/R600/address-space.ll (just triggered recently by some allocator
changes).
llvm-svn: 205005
|
|
|
|
|
|
|
|
|
|
|
|
| |
These are used in the ARM backends to aid type-checking on patterns involving
intrinsics. By making sure one argument is an extended/truncated version of
another.
However, there's no reason to limit them to just vectors types. For example
AArch64 has the instruction "uqshrn sD, dN, #imm" which would naturally use an
intrinsic taking an i64 and returning an i32.
llvm-svn: 205003
|