| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
Legalization of fp128 assumes things that we should have asserts for,
so that's another potential improvement.
Differential Revision: https://reviews.llvm.org/D38771
llvm-svn: 315485
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
section headers leaving only program headers and loadable segment data"
ubsan caught an issue I made where I was converting a null pointer to a
reference.
elf utils implements a particularly extreme form of stripping that I'd
like to support. eu-strip has an option called "strip-sections" that
removes all section headers and leaves only program headers and the
segment data. I have implemented this option partly as a test but mainly
because in Fuchsia we would like to use this option to minimize the size
of our executables. The other strip options that are on my list include
--strip-all and --strip-debug. This is a preliminary implementation that
I'd like to start using in Fuchsia builds if possible. This change
implements such a stripping option for llvm-objcopy
Differential Revision: https://reviews.llvm.org/D38335
llvm-svn: 315484
|
| |
|
|
| |
llvm-svn: 315483
|
| |
|
|
| |
llvm-svn: 315482
|
| |
|
|
| |
llvm-svn: 315481
|
| |
|
|
| |
llvm-svn: 315480
|
| |
|
|
| |
llvm-svn: 315479
|
| |
|
|
| |
llvm-svn: 315478
|
| |
|
|
| |
llvm-svn: 315477
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
parameterized emit() calls
Summary: This is not functional change to adopt new emit() API added in r313691.
Reviewed By: anemet
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38285
llvm-svn: 315476
|
| |
|
|
| |
llvm-svn: 315475
|
| |
|
|
| |
llvm-svn: 315474
|
| |
|
|
|
|
|
| |
getRelocationAddend should never be called on non SHT_RELA sections,
but changing that requires changing RelocVisitor.h.
llvm-svn: 315473
|
| |
|
|
| |
llvm-svn: 315472
|
| |
|
|
| |
llvm-svn: 315471
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: According to Intel docs this should take void const *. We had char*. The lack of const is the main issue.
Reviewers: RKSimon, zvi, igorb
Reviewed By: igorb
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38782
llvm-svn: 315470
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: I don't think this is necessary with i1 being illegal now.
Reviewers: RKSimon, zvi, guyblank
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D38784
llvm-svn: 315469
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The software pipeliner and the packetizer try to break dependence
between the post-increment instruction and the dependent memory
instructions by changing the base register and the offset value.
However, in some cases, the existing logic didn't work properly
and created incorrect offset value.
Patch by Jyotsna Verma.
llvm-svn: 315468
|
| |
|
|
| |
llvm-svn: 315467
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The pipeliner is generating a serial sequence that causes poor
register allocation when a post-increment instruction appears
prior to the use of the post-increment register. This occurs when
there is a circular set of dependences involved with a sequence
of instructions in the same cycle. In this case, there is no
serialization of the parallel semantics that will not cause an
additional register to be allocated.
This patch fixes the problem by changing the instructions so that
the post-increment instruction is used by the subsequent
instruction, which enables the register allocator to make a
better decision and not require another register.
Patch by Brendon Cahoon.
llvm-svn: 315466
|
| |
|
|
|
|
| |
This relands r315336 after fixing bot breakage.
llvm-svn: 315465
|
| |
|
|
|
|
|
|
| |
If both taskloop and task directives are used at the same time in one
program, we may ran into the situation when the particular type for task
directive is reused for taskloop directives. Patch fixes this problem.
llvm-svn: 315464
|
| |
|
|
| |
llvm-svn: 315463
|
| |
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D30295
llvm-svn: 315462
|
| |
|
|
| |
llvm-svn: 315461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Eg:
insert v4i32 V, (v2i16 X), 2 --> shuffle v8i16 V', X', {0,1,2,3,8,9,6,7}
This is a generalization of the IR fold in D38316 to handle insertion into a non-undef vector.
We may want to abandon that one if we can't find value in squashing the more specific pattern sooner.
We're using the existing legal shuffle target hook to avoid AVX512 horror with vXi1 shuffles.
There may be room for improvement in the shuffle lowering here, but that would be follow-up work.
Differential Revision: https://reviews.llvm.org/D38388
llvm-svn: 315460
|
| |
|
|
| |
llvm-svn: 315459
|
| |
|
|
|
|
| |
This reverts commit r315456.
llvm-svn: 315458
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The NumFixedArgs field of CallLoweringInfo is used by
TargetLowering::LowerCallTo to determine whether a given argument is passed
using the vararg calling convention or not (specifically, to set IsFixed for
each ISD::OutputArg).
Firstly, CallLoweringInfo::setLibCallee and CallLoweringInfo::setCallee both
incorrectly set NumFixedArgs based on the _previous_ args list. Secondly,
TargetLowering::LowerCallTo failed to increment NumFixedArgs when modifying
the argument list so a pointer is passed for the return value.
If your backend uses the IsFixed property or directly accesses NumFixedArgs,
it is _possible_ this change could result in codegen changes (although the
previous behaviour would have been incorrect). No such cases have been
identified during code review for any in-tree architecture.
Differential Revision: https://reviews.llvm.org/D37898
llvm-svn: 315457
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch adds timestamp verification for swiftmodule files.
- A new flag is provided to allows us to continue testing of the code
for embedding the__swift_ast. (git doesn't maintain timestamps)
- Adds a new test for fat (arm) binaries.
Differential revision: https://reviews.llvm.org/D38686
llvm-svn: 315456
|
| |
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38779
Patch by Chih-Mao Chen.
llvm-svn: 315455
|
| |
|
|
| |
llvm-svn: 315454
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Treat 'f()' as 'f(void)' rather than a function w/o a prototype.
Reviewers: Anastasia, yaxunl
Reviewed By: Anastasia, yaxunl
Subscribers: cfe-commits, echuraev, chapuni
Differential Revision: https://reviews.llvm.org/D33681
Re-apply revision 306653.
llvm-svn: 315453
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the renamed symbol.
Reviewers: ioeric
Reviewed By: ioeric
Subscribers: klimek, cfe-commits, arphaman
Differential Revision: https://reviews.llvm.org/D38723
llvm-svn: 315452
|
| |
|
|
|
|
|
|
| |
Reviewers: atanasyan
Differential Revision: https://reviews.llvm.org/D38620
llvm-svn: 315451
|
| |
|
|
| |
llvm-svn: 315450
|
| |
|
|
|
|
| |
from MC.
llvm-svn: 315449
|
| |
|
|
| |
llvm-svn: 315448
|
| |
|
|
| |
llvm-svn: 315447
|
| |
|
|
|
|
| |
Use range_loop where it simplifies.
llvm-svn: 315446
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This adds debug tracing to the table-generated assembly instruction matcher,
enabled by the -debug-only=asm-matcher option.
The changes in the target AsmParsers are to add an MCInstrInfo reference under
a consistent name, so that we can use it from table-generated code. This was
already being used this way for targets that use deprecation warnings, but 5
targets did not have it, and Hexagon had it under a different name to the other
backends.
llvm-svn: 315445
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Prevent dumping of characters in DumpDataExtractor() with
item_byte_size bigger than 8 bytes. This case is not supported by the
code and results in a crash because the code calls
DataExtractor::GetMaxU64Bitfield() -> GetMaxU64() that asserts for
byte size > 8 bytes.
* Teach DataExtractor::GetMaxU64(), GetMaxU32(), GetMaxS64() and
GetMaxU64_unchecked() how to handle byte sizes that are not a multiple
of 2. This allows DumpDataExtractor() to dump characters and booleans
with item_byte_size in the interval of [1, 8] bytes. Values that are
not a multiple of 2 would previously result in a crash because they
were not handled by GetMaxU64().
llvm-svn: 315444
|
| |
|
|
|
|
|
|
| |
Adding this test files now so after another commit that will add a new pattern for
TESTM and TESTNM instructions will show the improvemnts that have been done.
Change-Id: If3908b7f91897d764053312365a2bc1de78b291d
llvm-svn: 315443
|
| |
|
|
| |
llvm-svn: 315442
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is PR34546.
Currently LLD creates output sections even if it has no input sections,
but its command contains an assignment.
Committed code just assigns the same flag that was used in previous
live section.
That does not work sometimes. For example if we have following script:
.ARM.exidx : { *(.ARM.exidx*) }
.foo : { _foo = 0; } }
Then first section has SHF_LINK_ORDER flag. But section foo should not.
That was a reason of crash in OutputSection::finalize(). LLD tried to calculate
Link value, calling front() on empty input sections list.
We should only keep access flags and omit all others when creating such sections.
Patch fixes the crash observed.
Differential revision: https://reviews.llvm.org/D37736
llvm-svn: 315441
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
control flow to successors
This patch fixes the miscompile that happens when PRE hoists loads across guards and
other instructions that don't always pass control flow to their successors. PRE is now prohibited
to hoist across such instructions because there is no guarantee that the load standing after such
instruction is still valid before such instruction. For example, a load from under a guard may be
invalid before the guard in the following case:
int array[LEN];
...
guard(0 <= index && index < LEN);
use(array[index]);
Differential Revision: https://reviews.llvm.org/D37460
llvm-svn: 315440
|
| |
|
|
|
|
|
|
|
|
|
| |
deserialization."
This is breaking a build of https://github.com/abseil/abseil-cpp and so
likely not really NFC. Also reverted subsequent r314956/7.
I'll forward reproduction instructions to Richard.
llvm-svn: 315439
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sinking of unordered atomic load into loop must be disallowed because it turns
a single load into multiple loads. The relevant section of the documentation
is: http://llvm.org/docs/Atomics.html#unordered, specifically the Notes for
Optimizers section. Here is the full text of this section:
> Notes for optimizers
> In terms of the optimizer, this **prohibits any transformation that
> transforms a single load into multiple loads**, transforms a store into
> multiple stores, narrows a store, or stores a value which would not be
> stored otherwise. Some examples of unsafe optimizations are narrowing
> an assignment into a bitfield, rematerializing a load, and turning loads
> and stores into a memcpy call. Reordering unordered operations is safe,
> though, and optimizers should take advantage of that because unordered
> operations are common in languages that need them.
Patch by Daniil Suchkov!
Reviewed By: reames
Differential Revision: https://reviews.llvm.org/D38392
llvm-svn: 315438
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRCE should not apply when the safe iteration range is proved to be empty.
In this case we do unneeded job creating pre/post loops and then never
go to the main loop.
This patch makes IRCE not apply to empty safe ranges, adds test for this
situation and also modifies one of existing tests where it used to happen
slightly.
Reviewed By: anna
Differential Revision: https://reviews.llvm.org/D38577
llvm-svn: 315437
|
| |
|
|
| |
llvm-svn: 315436
|