| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.
Note: This patch is one of a series of patches to replace *all* std::sort to llvm::sort. Refer the comments section in D44363 for a list of all the required patches.
Reviewers: kparzysz
Reviewed By: kparzysz
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D44857
llvm-svn: 328430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
r327219 added wrappers to std::sort which randomly shuffle the container before sorting.
This will help in uncovering non-determinism caused due to undefined sorting
order of objects having the same key.
To make use of that infrastructure we need to invoke llvm::sort instead of std::sort.
Reviewers: tstellar, RKSimon, arsenm
Reviewed By: arsenm
Subscribers: arsenm, kzhuravl, wdng, nhaehnle, yaxunl, dstuttard, tpr, llvm-commits, t-tye
Differential Revision: https://reviews.llvm.org/D44856
llvm-svn: 328429
|
|
|
|
|
|
|
|
|
|
|
|
| |
This pattern came up in PR36682:
https://bugs.llvm.org/show_bug.cgi?id=36682
https://godbolt.org/g/LhuD9A
Equality checks are planned as a follow-up enhancement.
Differential Revision: https://reviews.llvm.org/D44367
llvm-svn: 328426
|
|
|
|
| |
llvm-svn: 328425
|
|
|
|
|
|
|
|
| |
attribute.
This reduces the size of llvm-mc by at least 150k since we no longer have to multiply the attribute across 7 tables.
llvm-svn: 328416
|
|
|
|
|
|
| |
The 3DNow instructions are encoded a little weird, but we can still represent it as an opcode map.
llvm-svn: 328410
|
|
|
|
|
|
|
|
| |
These nodes only use the lower 32 bits of their inputs so we can use SimplifyDemandedBits to simplify them.
Differential Revision: https://reviews.llvm.org/D44375
llvm-svn: 328405
|
|
|
|
|
|
|
|
|
|
| |
offsets for code models other than small/medium. For JIT application,
memory layout is less controlled and can result in truncations
otherwise.
Patch based on one by Olexa Bilaniuk!
llvm-svn: 328400
|
|
|
|
|
|
|
| |
Fixes layering, since Transforms/Utils doesn't depend on CodeGen, so
shouldn't include headers from it.
llvm-svn: 328399
|
|
|
|
|
|
| |
Should be NFC since nothing used the enum value. The instruction descriptions are generated from tablegen which had the correct value.
llvm-svn: 328398
|
|
|
|
|
|
| |
ValueTypes.h is implemented in IR already.
llvm-svn: 328397
|
|
|
|
|
|
|
|
|
| |
This is used by llvm tblgen as well as by LLVM Targets, so the only
common place is Support for now. (maybe we need another target for these
sorts of things - but for now I'm at least making them correct & we can
make them better if/when people have strong feelings)
llvm-svn: 328395
|
|
|
|
|
|
|
|
| |
This includes llvm-c/TargetMachine.h which is logically part of
libTarget (since libTarget implements llvm-c/TargetMachine.h's
functions).
llvm-svn: 328394
|
|
|
|
|
|
|
|
|
| |
This is used from llvm tblgen and the X86Disassembler - the only common
library (apart from TableGen, which probably doesn't make sense to have
as a dependency from a release tool (rather than a use-while-building-llvm
tool) of LLVM)
llvm-svn: 328393
|
|
|
|
|
|
|
| |
It's implemented in Target & include from other Target headers, so the
header should be in Target.
llvm-svn: 328392
|
|
|
|
| |
llvm-svn: 328387
|
|
|
|
|
|
|
| |
Both GCC and MSVC only look at the low byte of a boolean when it is
passed.
llvm-svn: 328386
|
|
|
|
|
|
| |
subdirectory
llvm-svn: 328379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PostOrderFunctionAttrs pass
Summary:
This was motivated by absence of PrunEH functionality in new PM.
It was decided that a proper way to do PruneEH is to add NoUnwind inference
into PostOrderFunctionAttrs and then perform normal SimplifyCFG on top.
This change generalizes attribute handling implemented for (a removal of)
Convergent attribute, by introducing a generic builder-like class
AttributeInferer
It registers all the attribute inference requests, storing per-attribute
predicates into a vector, and then goes through an SCC Node, scanning all
the instructions for not breaking attribute assumptions.
The main idea is that as soon all the instructions from all the functions
of SCC Node conform to attribute assumptions then we are free to infer
the attribute as set for all the functions of SCC Node.
It handles two distinct cases of attributes:
- those that might break due to derefinement of the function code
for these attributes we are allowed to apply inference only if all the
functions are "exact definitions". Example - NoUnwind.
- those that do not care about derefinement
for these attributes we are allowed to apply inference as soon as we see
any function definition. Example - removal of Convergent attribute.
Also in this commit:
* Converted all the FunctionAttrs tests to use FileCheck and added new-PM
invocations to them
* FunctionAttrs/convergent.ll test demonstrates a difference in behavior between
new and old PM implementations. Marked with FIXME.
* PruneEH tests were converted to new-PM as well, using function-attrs+simplify-cfg
combo as intended
* some of "other" tests were updated since function-attrs now infers 'nounwind'
even for old PM pipeline
* -disable-nounwind-inference hidden option added as a possible workaround for a supposedly
rare case when nounwind being inferred by default presents a problem
Reviewers: chandlerc, jlebar
Reviewed By: jlebar
Subscribers: eraman, llvm-commits
Differential Revision: https://reviews.llvm.org/D44415
llvm-svn: 328377
|
|
|
|
| |
llvm-svn: 328372
|
|
|
|
| |
llvm-svn: 328367
|
|
|
|
| |
llvm-svn: 328366
|
|
|
|
|
|
| |
This avoids unnecessary splitting due to uninteresting immediates.
llvm-svn: 328364
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was reverted several times due to what ultimately turned out
to be incompatibilities in our serialized hash table format.
Several changes went in prior to this to fix those issues since
they were more fundamental and independent of supporting injected
sources, so now that those are fixed this change should hopefully
pass.
llvm-svn: 328363
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The branch relaxation pass collects sizes of all instructions at the
beginning, before any changes have been made. It then performs one pass
over all branches to see which ones need to be extended. It does not
account for the case when a previously valid branch becomes out-of-range
due to relaxing other branches.
This approach fixes this problem by assuming from the beginning that
all extendable branches have been extended. This may cause unneeded
relaxation in some cases, but avoids iteration and recomputing instruction
sizes.
llvm-svn: 328360
|
|
|
|
|
|
|
|
|
|
|
|
| |
The HexagonExpandCondsets pass is incorrectly removing the dead
flag on a definition that is really dead, and adding a kill flag
to a use that is tied to a definition. This causes an assert later
during the machine scheduler when querying the live interval
information.
Patch by Brendon Cahoon.
llvm-svn: 328357
|
|
|
|
| |
llvm-svn: 328356
|
|
|
|
|
|
|
|
| |
Optimize Ry = add(Rx,#n); memw(Ry+#0) = Rz => memw(Rx,#n) = Rz.
Patch by Jyotsna Verma.
llvm-svn: 328355
|
|
|
|
| |
llvm-svn: 328353
|
|
|
|
|
|
| |
counterparts.
llvm-svn: 328352
|
|
|
|
|
|
|
|
|
|
|
| |
attribute for AMDGPU
- Remove use of the opencl and amdopencl environment member of the target triple for the AMDGPU target.
- Use function attribute to communicate to the AMDGPU backend to add implicit arguments for OpenCL kernels for the AMDHSA OS.
Differential Revision: https://reviews.llvm.org/D43736
llvm-svn: 328349
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When investigating bugs in PDB generation, the first step is
often to do the same link with link.exe and then compare PDBs.
But comparing PDBs is hard because two completely different byte
sequences can both be correct, so it hampers the investigation when
you also have to spend time figuring out not just which bytes are
different, but also if the difference is meaningful.
This patch fixes a couple of cases related to string table emission,
hash table emission, and the order in which we emit strings that
makes more of our bytes the same as the bytes generated by MS PDBs.
Differential Revision: https://reviews.llvm.org/D44810
llvm-svn: 328348
|
|
|
|
|
|
|
|
|
|
|
|
| |
HexagonGenMux would collapse pairs of predicated transfers if it assumed
that the predicated .new forms cannot be created. Turns out that generating
mux is preferable in almost all cases.
Introduce an option -hexagon-gen-mux-threshold that controls the minimum
distance between the instruction defining the predicate and the later of
the two transfers. If the distance is closer than the threshold, mux will
not be generated. Set the threshold to 0 by default.
llvm-svn: 328346
|
|
|
|
|
|
| |
Patch by Anand Kodnani.
llvm-svn: 328344
|
|
|
|
|
|
| |
unit
llvm-svn: 328343
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Porting HWASan to Linux x86-64, first of the three patches, LLVM part.
The approach is similar to ARM case, trap signal is used to communicate
memory tag check failure. int3 instruction is used to generate a signal,
access parameters are stored in nop [eax + offset] instruction immediately
following the int3 one.
One notable difference is that x86-64 has to untag the pointer before use
due to the lack of feature comparable to ARM's TBI (Top Byte Ignore).
Reviewers: eugenis
Subscribers: kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D44699
llvm-svn: 328342
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes PR36658, "Constant pool entry out of range!" in Thumb1 mode.
In ARMConstantIslands::optimizeThumb2JumpTables() in Thumb1 mode,
adjustBBOffsetsAfter() is not calculating postOffset correctly by
properly accounting for the padding that is required for the constant pool
that immediately follows the jump table branch instruction.
Reviewers: t.p.northover, eli.friedman
Reviewed By: t.p.northover
Subscribers: chrib, tstellar, javed.absar, kristof.beyls, llvm-commits
Differential Revision: https://reviews.llvm.org/D44709
llvm-svn: 328341
|
|
|
|
|
|
|
|
|
| |
- Fix checking for vector predicate registers.
- Avoid speculating llvm.lifetime.end intrinsic.
Patch by Harsha Jagasia and Brendon Cahoon.
llvm-svn: 328339
|
|
|
|
|
|
| |
Add missing non-VEX and (V)PMOVMSKB instructions to the pattern
llvm-svn: 328338
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D44817
llvm-svn: 328336
|
|
|
|
| |
llvm-svn: 328334
|
|
|
|
|
|
|
|
|
| |
When converting an instruction to the wider version, copy any
subregisters if the original operand has a subregister.
Patch by Brendon Cahoon.
llvm-svn: 328333
|
|
|
|
|
|
| |
function unit
llvm-svn: 328331
|
|
|
|
|
|
| |
JSAGU/JSTC function units
llvm-svn: 328328
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds functions to allow MachineLICM to hoist invariant stores.
Currently, MachineLICM does not hoist any store instructions, however
when storing the same value to a constant spot on the stack, the store
instruction should be considered invariant and be hoisted. The function
isInvariantStore iterates each operand of the store instruction and checks
that each register operand satisfies isCallerPreservedPhysReg. The store
may be fed by a copy, which is hoisted by isCopyFeedingInvariantStore.
This patch also adds the PowerPC changes needed to consider the stack
register as caller preserved.
Differential Revision: https://reviews.llvm.org/D40196
llvm-svn: 328326
|
|
|
|
| |
llvm-svn: 328324
|
|
|
|
| |
llvm-svn: 328323
|
|
|
|
| |
llvm-svn: 328322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Loads and stores can only shift the offset register by the size of the value
being loaded, but currently the DAGCombiner will reduce the width of the load
if it's followed by a trunc making it impossible to later combine the shift.
Solve this by implementing shouldReduceLoadWidth for the AArch64 backend and
make it prevent the width reduction if this is what would happen, though do
allow it if reducing the load width will let us eliminate a later sign or zero
extend.
Differential Revision: https://reviews.llvm.org/D44794
llvm-svn: 328321
|
|
|
|
|
|
| |
This was due to a misunderstanding over what llvm calls a micro-op (retirement unit) is actually called a macro-op on the AMD/Jaguar target. Folded loads don't affect num macro ops.
llvm-svn: 328320
|