| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 177342
|
| |
|
|
|
|
|
|
|
|
| |
For each compile unit, we want to register a function that will flush that
compile unit. Otherwise, __gcov_flush() would only flush the counters within the
current compile unit, and not any outside of it.
PR15191 & <rdar://problem/13167507>
llvm-svn: 177340
|
| |
|
|
| |
llvm-svn: 177339
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
PPC64 supports unaligned loads and stores of 64-bit values, but
in order to use the r+i forms, the offset must be a multiple of 4.
Unfortunately, this cannot always be determined by examining the
immediate itself because it might be available only via a TOC entry.
In order to get around this issue, we additionally predicate the
selection of the r+i form on the alignment of the load or store
(forcing it to be at least 4 in order to select the r+i form).
llvm-svn: 177338
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default logic marks them as too expensive.
For example, before this patch we estimated:
cost of 16 for instruction: %r = uitofp <4 x i16> %v0 to <4 x float>
While this translates to:
vmovl.u16 q8, d16
vcvt.f32.u32 q8, q8
All other costs are left to the values assigned by the fallback logic. Theses
costs are mostly reasonable in the sense that they get progressively more
expensive as the instruction sequences emitted get longer.
radar://13445992
llvm-svn: 177334
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix cost of some "cheap" cast instructions. Before this patch we used to
estimate for example:
cost of 16 for instruction: %r = fptoui <4 x float> %v0 to <4 x i16>
While we would emit:
vcvt.s32.f32 q8, q8
vmovn.i32 d16, q8
vuzp.8 d16, d17
All other costs are left to the values assigned by the fallback logic. Theses
costs are mostly reasonable in the sense that they get progressively more
expensive as the instruction sequences emitted get longer.
radar://13434072
llvm-svn: 177333
|
| |
|
|
|
|
| |
Also add some checks to not merge globals used within landing pad instructions or marked as "used".
llvm-svn: 177331
|
| |
|
|
|
|
|
|
|
| |
Hal Finkel recently added code to allow unaligned memory references
for PowerPC. Two tests were temporarily modified with
-disable-ppc-unaligned to keep them from failing. This patch adjusts
the expected code generation for the unaligned references.
llvm-svn: 177328
|
| |
|
|
| |
llvm-svn: 177327
|
| |
|
|
|
|
|
|
|
|
| |
We hitch a ride with the existing OpndItins class that was used to add
instruction itinerary classes in the many multiclasses in this file.
Use the link provided by the X86FoldableSchedWrite.Folded to find the
right SchedWrite for folded loads.
llvm-svn: 177326
|
| |
|
|
|
|
|
|
|
| |
This new-style scheduling information is going to replace the
instruction iteneraries.
This also serves as a test case for Andy's fix in r177317.
llvm-svn: 177323
|
| |
|
|
|
|
|
|
| |
This handles the case where we have an inbounds GEP with alloca as the pointer.
This fixes the regression in PR12750 and rdar://13286434.
Note that we can also fix this by handling some GEP cases in isKnownNonNull.
llvm-svn: 177321
|
| |
|
|
|
|
|
|
| |
Properly handle cases where a group of instructions have different
SchedRW lists with the same itinerary class.
This was supposed to work, but I left in an early break.
llvm-svn: 177317
|
| |
|
|
|
|
|
|
|
|
| |
Apparently my final cleanup to use a relevant suffix for these tests before
committing r176831 caused them to stop running since lit wasn't configured to
run tests with that suffix in those directories (why don't we just have a
global suffix list?). So, add the suffix to the relevant directories & fix the
test that has bitrotted over the last week due to my debug info schema changes.
llvm-svn: 177315
|
| |
|
|
| |
llvm-svn: 177314
|
| |
|
|
| |
llvm-svn: 177298
|
| |
|
|
| |
llvm-svn: 177296
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit fixes an assert that would occur on loops with large constant counts
(like looping for ((uint32_t) -1) iterations on PPC64). The existing code did
not handle counts that it computed to be negative (asserting instead), but
these can be created with valid inputs.
This bug was discovered by bugpoint while I was attempting to isolate a
completely different problem.
Also, in writing test cases for the negative-count problem, I discovered that
the ori/lsi handling was broken (there was a typo which caused the logic that
was supposed to detect these pairs and extract the iteration count to always
fail). This has now also been corrected (and is covered by one of the new test
cases).
llvm-svn: 177295
|
| |
|
|
|
|
|
|
| |
Because the initial-value constants had not been added to the list
of instructions considered for DCE the resulting code had redundant
constant-materialization instructions.
llvm-svn: 177294
|
| |
|
|
|
|
|
| |
The always-true "(int)Int == (signed)Int" comparison was found
while experimenting with a potential new Clang warning.
llvm-svn: 177290
|
| |
|
|
| |
llvm-svn: 177284
|
| |
|
|
|
|
| |
And enables SmallVector's pod optimizations.
llvm-svn: 177281
|
| |
|
|
| |
llvm-svn: 177280
|
| |
|
|
|
|
|
|
|
|
| |
the vector case (because
we weren't differntiating floating-point zeroinitializers from other zero-initializers)
which was causing problems for code relying upon a + (+0.0f) to, eg, flush denormals to
0. Make the scalar and vector cases have the same behaviour.
llvm-svn: 177279
|
| |
|
|
|
|
| |
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 177277
|
| |
|
|
|
|
| |
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 177276
|
| |
|
|
|
|
| |
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 177275
|
| |
|
|
|
|
| |
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 177274
|
| |
|
|
|
|
| |
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 177273
|
| |
|
|
|
|
| |
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 177272
|
| |
|
|
|
|
|
|
|
|
| |
Unfortunately the previous fix for inserting waits for unordered
defines wasn't sufficient, cause it's possible that even ordered
defines are only partially used (or not used at all).
Signed-off-by: Christian König <christian.koenig@amd.com>
Reviewed-by: Tom Stellard <thomas.stellard@amd.com>
llvm-svn: 177271
|
| |
|
|
|
|
| |
equal strings are merged by the linker. Observed up to 1% binary size reduction. Thanks to Anton Korobeynikov for the suggestion
llvm-svn: 177264
|
| |
|
|
|
|
|
|
| |
SmallVector and DenseMap.
This speeds up SROA by 25% on PR15412.
llvm-svn: 177259
|
| |
|
|
|
|
|
|
| |
MinGW is almost completely compatible to MSVC, with the exception of the _tls_array global not being available.
Patch by David Nadlinger!
llvm-svn: 177257
|
| |
|
|
|
|
|
|
|
|
|
| |
The linker sorts the .tls$<xyz> sections by name, and we need
to make sure any extra sections we produce (e.g. for weak globals)
always end up between .tls$AAA and .tls$ZZZ, even if the name
starts with e.g. an underscore.
Patch by David Nadlinger!
llvm-svn: 177256
|
| |
|
|
|
|
| |
module name in a separate field, thus not duplicating this information if every description. This decreases the binary size (observed up to 3%). https://code.google.com/p/address-sanitizer/issues/detail?id=168 . This changes the asan API version. llvm-part
llvm-svn: 177254
|
| |
|
|
|
|
| |
saves a bit of compile time and reduces the number of redundant global strings generated by asan (https://code.google.com/p/address-sanitizer/issues/detail?id=167)
llvm-svn: 177250
|
| |
|
|
|
|
|
| |
This computes the type of an instruction operand or result based on the
records in the instruction's ins and outs lists.
llvm-svn: 177244
|
| |
|
|
|
|
| |
immediate.
llvm-svn: 177243
|
| |
|
|
| |
llvm-svn: 177242
|
| |
|
|
|
|
| |
Seems some accidental C++11 crept in there. Reported by the C++98 buildbots.
llvm-svn: 177241
|
| |
|
|
|
|
|
|
|
|
| |
moved it to retain-block-escape-analysis.ll.
*NOTE* I verified that the original bug behind
dont-infinite-loop-during-block-escape-analysis.ll occurs when using opt on
retain-block-escape-analysis.ll.
llvm-svn: 177240
|
| |
|
|
|
|
|
|
|
|
| |
This is the first step to making all DIScopes have a common metadata prefix (so
that things (using directives, for example) that can appear in any scope can be
added to that common prefix). DIFile is itself a DIScope so the common prefix
of all DIScopes cannot be a DIFile - instead it's the raw filename/directory
name pair.
llvm-svn: 177239
|
| |
|
|
| |
llvm-svn: 177238
|
| |
|
|
| |
llvm-svn: 177236
|
| |
|
|
|
|
|
| |
Not passing vector references around makes it possible to use
SmallVector in most places.
llvm-svn: 177235
|
| |
|
|
| |
llvm-svn: 177234
|
| |
|
|
|
|
| |
Patch by Stephen Checkoway.
llvm-svn: 177233
|
| |
|
|
|
|
|
|
| |
This test makes sure that the ObjCARC escape analysis looks at the uses of
instructions which copy the block pointer value by checking all four cases where
that can occur.
llvm-svn: 177232
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change cleans up two issues with Altivec register spilling:
1. The spilling code was inefficient (using two instructions, and add and a
load, when just one would do)
2. The code assumed that r0 would always be available (true for now, but this
will change)
The new code handles VR spilling just like GPR spills but forced into r+r mode.
As a result, when any VR spills are present, we must now always allocate the
register-scavenger spill slot.
llvm-svn: 177231
|