| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
but allowed you to arbitrarily set the category of the float.
The category which an APFloat belongs to should be dependent on the
actual value that the APFloat has, not be arbitrarily passed in by the
user. This will prevent inconsistency bugs where the category and the
actual value in APFloat differ.
I also fixed up all of the references to this constructor (which were
only in LLVM).
llvm-svn: 185095
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
algorithm when assigning EnumValues to the synthesized registers.
The current algorithm, LessRecord, uses the StringRef compare_numeric
function. This function compares strings, while handling embedded numbers.
For example, the R600 backend registers are sorted as follows:
T1
T1_W
T1_X
T1_XYZW
T1_Y
T1_Z
T2
T2_W
T2_X
T2_XYZW
T2_Y
T2_Z
In this example, the 'scaling factor' is dEnum/dN = 6 because T0, T1, T2
have an EnumValue offset of 6 from one another. However, in other parts
of the register bank, the scaling factors are different:
dEnum/dN = 5:
KC0_128_W
KC0_128_X
KC0_128_XYZW
KC0_128_Y
KC0_128_Z
KC0_129_W
KC0_129_X
KC0_129_XYZW
KC0_129_Y
KC0_129_Z
The diff lists do not work correctly because different kinds of registers have
different 'scaling factors'. This new algorithm, LessRecordRegister, tries to
enforce a scaling factor of 1. For example, the registers are now sorted as
follows:
T1
T2
T3
...
T0_W
T1_W
T2_W
...
T0_X
T1_X
T2_X
...
KC0_128_W
KC0_129_W
KC0_130_W
...
For the Mips and R600 I see a 19% and 6% reduction in size, respectively. I
did see a few small regressions, but the differences were on the order of a
few bytes (e.g., AArch64 was 16 bytes). I suspect there will be even
greater wins for targets with larger register files.
Patch reviewed by Jakob.
rdar://14006013
llvm-svn: 185094
|
| |
|
|
|
|
| |
Because Registry.h is using the LLVM_DELETED_FUNCTION macro.
llvm-svn: 185087
|
| |
|
|
| |
llvm-svn: 185086
|
| |
|
|
|
|
| |
such as <3 x float>, which are popular in graphics.
llvm-svn: 185085
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of this test was to check boundary conditions for the size
of an ALU clause. This test is very sensitive to changes to the
optimizer or scheduler, because it requires an exact number of ALU
instructions in order to remain valid. It's not good to have a test
this sensitive, because it is confusing to developers who implement
optimizations and then 'break' the test.
I'm not sure if there is a good way to test these limits using lit, but
if I can come up with replacement test that isn't as sensitive I'll add
it back to the tree.
llvm-svn: 185084
|
| |
|
|
|
|
|
|
|
| |
Use vectorized instruction instead of original instruction anchored in the
original loop.
Fixes PR16452 and t2075.c of PR16455.
llvm-svn: 185081
|
| |
|
|
|
|
|
|
| |
It fixes PR16338 (ICE when compiling very large two-dimensional array).
Differential Revision: http://llvm-reviews.chandlerc.com/D1043
llvm-svn: 185080
|
| |
|
|
| |
llvm-svn: 185073
|
| |
|
|
| |
llvm-svn: 185072
|
| |
|
|
| |
llvm-svn: 185071
|
| |
|
|
| |
llvm-svn: 185070
|
| |
|
|
| |
llvm-svn: 185069
|
| |
|
|
| |
llvm-svn: 185068
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add pseudo conditional store instructions, so that we use:
branch foo:
store
foo:
instead of:
load
branch foo:
move
foo:
store
z196 has real 32-bit and 64-bit conditional stores, but we don't use
any z196 instructions yet.
llvm-svn: 185065
|
| |
|
|
|
|
| |
ThreadSanitizer; Evgeniy Stepanov: MemorySanitizer)
llvm-svn: 185064
|
| |
|
|
| |
llvm-svn: 185061
|
| |
|
|
|
|
|
|
| |
This is essentially reverting one piece of 184793 to try to fix one of Apple's
buildbots. I will check with Eric to see if this is OK or if we need to find
some other solution.
llvm-svn: 185060
|
| |
|
|
|
|
|
|
|
|
|
| |
There are a few valid situation where we care about the structure inside a
directory, but not about the directory itself. A simple example is for unit
testing directory traversal.
PathV1 had a function like this, add one to V2 and port existing users of the
created temp file and delete it hack to using it.
llvm-svn: 185059
|
| |
|
|
| |
llvm-svn: 185052
|
| |
|
|
|
|
|
|
|
|
| |
When we store values for reversed induction stores we must not store the
reversed value in the vectorized value map. Another instruction might use this
value.
This fixes 3 test cases of PR16455.
llvm-svn: 185051
|
| |
|
|
|
|
| |
result categories, and result statuses.
llvm-svn: 185050
|
| |
|
|
|
|
|
|
| |
The Builtin attribute is an attribute that can be placed on function call site that signal that even though a function is declared as being a builtin,
rdar://problem/13727199
llvm-svn: 185049
|
| |
|
|
| |
llvm-svn: 185047
|
| |
|
|
| |
llvm-svn: 185045
|
| |
|
|
|
|
| |
result categories, and result status.
llvm-svn: 185044
|
| |
|
|
|
|
| |
result categories, and result status.
llvm-svn: 185043
|
| |
|
|
|
|
| |
post-order because we grow chains upwards.
llvm-svn: 185041
|
| |
|
|
|
|
| |
outerloops from iterating over the instructions.
llvm-svn: 185040
|
| |
|
|
|
|
| |
!APFloat.isDenormal => APFloat.isNormal.
llvm-svn: 185037
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Currently inside APFloat fcNormal still implies the old definition of Normal
(i.e. isFiniteNonZero) instead of the proper IEEE-754R definition that the
external method isNormal() uses.
This patch prepares for the internal switch inside APFloat by converting all
references that check if a category is fcNormal directly with an indirect call
via isFiniteNonZero().
llvm-svn: 185036
|
| |
|
|
|
|
| |
This reverts commit r185020
llvm-svn: 185032
|
| |
|
|
|
|
|
|
| |
Option groups don't have prefixes. Option dumping is basically dead
code unless there is something wrong with the option table, so this
isn't an important crasher.
llvm-svn: 185031
|
| |
|
|
| |
llvm-svn: 185030
|
| |
|
|
|
|
|
| |
function to lookup the proper tablegen'ed register enumeration. Previously,
it was using the encoded value directly.
llvm-svn: 185026
|
| |
|
|
|
|
|
|
| |
not used for incompatible calling conventions.
(Currently, ARM 'this'-returns are handled in the standard calling convention case by treating R0 as preserved and doing some extra magic in LowerCallResult; this may not apply to calling conventions added in the future so this patch provides and documents an interface for indicating such)
llvm-svn: 185024
|
| |
|
|
|
|
|
|
| |
No functionality change.
It should suffice to check the type of a debug info metadata, instead of
calling Verify.
llvm-svn: 185020
|
| |
|
|
| |
llvm-svn: 185016
|
| |
|
|
| |
llvm-svn: 185015
|
| |
|
|
| |
llvm-svn: 185012
|
| |
|
|
|
|
|
|
| |
adds and
subs.
llvm-svn: 185011
|
| |
|
|
| |
llvm-svn: 184974
|
| |
|
|
| |
llvm-svn: 184973
|
| |
|
|
|
|
| |
Patch by 罗勇刚(Yonggang Luo).
llvm-svn: 184971
|
| |
|
|
| |
llvm-svn: 184969
|
| |
|
|
|
|
| |
This allows for targeting the ARMv8 AArch32 variant.
llvm-svn: 184967
|
| |
|
|
|
|
| |
consider them as a candidate for replacement of instructions to be visited.
llvm-svn: 184966
|
| |
|
|
|
|
|
|
|
|
| |
Unfortunately this addresses two issues (by the time I'd disentangled the logic
it wasn't worth putting it back to half-broken):
+ Coprocessor instructions should all be predicable in Thumb mode.
+ BKPT should never be predicable.
llvm-svn: 184965
|
| |
|
|
|
|
|
| |
The barrier instructions are only "always-execute" in ARM mode, they can quite
happily sit inside an IT block in Thumb.
llvm-svn: 184964
|
| |
|
|
|
|
| |
Make v4 the default ARM architecture attribute, to match CodeGen.
llvm-svn: 184962
|