| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Previously it is not allowed for each MBB to have successors with both known and
unknown probabilities. However, this may be too strict as at this stage we could
not always guarantee that. It is better to remove this restriction now, and I
will work on validating MBB's successors' probabilities first (for example,
check if the sum is approximate one).
llvm-svn: 254402
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Statistical Profiling Extension is an optional extension to
ARMv8.2-A. Since it is an optional extension, I have added the
FeatureSPE subtarget feature to control it. The assembler-visible parts
of this extension are the new "psb csync" instruction, which is
equivalent to "hint #17", and a number of system registers.
Differential Revision: http://reviews.llvm.org/D15021
llvm-svn: 254401
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add ARMv8.2-A to TargetParser, so that it can be used by the clang
command-line options and the .arch directive.
Most testing of this will be done in clang, checking that the
command-line options that this enables work.
Differential Revision: http://reviews.llvm.org/D15037
llvm-svn: 254400
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds subtarget features for ARMv8.2-A, which builds on (and
requires the features from) ARMv8.1-A. Most assembler-visible features
of ARMv8.2-A are system instructions, and are all required parts of the
architecture, so just depend on the HasV8_2aOps subtarget feature.
There is also one large, optional feature, which adds 16-bit floating
point versions of all existing floating-point instructions (VFP and
SIMD), this is represented by the FeatureFullFP16 subtarget feature.
Differential Revision: http://reviews.llvm.org/D15036
llvm-svn: 254399
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dblaikie, pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15064
llvm-svn: 254391
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: dblaikie, pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15063
llvm-svn: 254390
|
|
|
|
|
|
|
|
| |
memory on the left hand side of the fsub/fdiv operations in their patterns.
Not sure how to test this. I noticed by inspection in the isel tables where the same pattern tried to produce DIV and DIVR or SUB and SUBR.
llvm-svn: 254388
|
|
|
|
| |
llvm-svn: 254387
|
|
|
|
|
|
| |
types to size_t to match.
llvm-svn: 254386
|
|
|
|
|
|
| |
manually. NFC
llvm-svn: 254385
|
|
|
|
|
|
| |
and array size. NFC
llvm-svn: 254384
|
|
|
|
| |
llvm-svn: 254383
|
|
|
|
|
|
| |
Interestingly the original code may have had a bug because it was passing the byte size of a uint16_t array instead of the number of entries.
llvm-svn: 254382
|
|
|
|
|
|
| |
size that I would have otherwise cconverted to array_lengthof. NFC
llvm-svn: 254381
|
|
|
|
| |
llvm-svn: 254380
|
|
|
|
|
|
| |
Reported by: David Blaikie
llvm-svn: 254378
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interfaces, and update all uses of old interfaces.
(This is the second attempt to submit this patch. The first caused two assertion
failures and was reverted. See https://llvm.org/bugs/show_bug.cgi?id=25687)
The patch in http://reviews.llvm.org/D13745 is broken into four parts:
1. New interfaces without functional changes (http://reviews.llvm.org/D13908).
2. Use new interfaces in SelectionDAG, while in other passes treat probabilities
as weights (http://reviews.llvm.org/D14361).
3. Use new interfaces in all other passes.
4. Remove old interfaces.
This patch is 3+4 above. In this patch, MBB won't provide weight-based
interfaces any more, which are totally replaced by probability-based ones.
The interface addSuccessor() is redesigned so that the default probability is
unknown. We allow unknown probabilities but don't allow using it together
with known probabilities in successor list. That is to say, we either have a
list of successors with all known probabilities, or all unknown
probabilities. In the latter case, we assume each successor has 1/N
probability where N is the number of successors. An assertion checks if the
user is attempting to add a successor with the disallowed mixed use as stated
above. This can help us catch many misuses.
All uses of weight-based interfaces are now updated to use probability-based
ones.
Differential revision: http://reviews.llvm.org/D14973
llvm-svn: 254377
|
|
|
|
| |
llvm-svn: 254372
|
|
|
|
|
|
|
| |
Nobody was checking the returnvalue of recede()/advance() so we can
simply replace this code with asserts.
llvm-svn: 254371
|
|
|
|
|
|
|
| |
This is in preparation to expose the RegisterOperands class as
RegisterPressure API.
llvm-svn: 254368
|
|
|
|
|
|
|
|
|
|
| |
probability-based interfaces, and update all uses of old interfaces."
and the follow-up r254356: "Fix a bug in MachineBlockPlacement that may cause assertion failure during BranchProbability construction."
Asserts were firing in Chromium builds. See PR25687.
llvm-svn: 254366
|
|
|
|
| |
llvm-svn: 254364
|
|
|
|
| |
llvm-svn: 254363
|
|
|
|
|
|
| |
Patch by Justin Lebar
llvm-svn: 254362
|
|
|
|
|
|
|
|
| |
BranchProbability construction.
The root cause is the rounding behavior in BranchProbability construction. We may consider to use truncation instead in the future.
llvm-svn: 254356
|
|
|
|
|
|
|
| |
Detect unsafe byval function arguments and move them to the unsafe
stack.
llvm-svn: 254353
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SDAG currently can emit debug location for function parameters when
an llvm.dbg.declare points to either a function argument SSA temp,
or to an AllocaInst. This change extends this logic by adding a
fallback case when neither of the above is true.
This is required for SafeStack, which may copy the contents of a
byval function argument into something that is not an alloca, and
then describe the target as the new location of the said argument.
llvm-svn: 254352
|
|
|
|
|
|
|
|
| |
The current code does not take alloca array size into account and,
as a result, considers any access past the first array element to be
unsafe.
llvm-svn: 254350
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
interfaces, and update all uses of old interfaces.
The patch in http://reviews.llvm.org/D13745 is broken into four parts:
1. New interfaces without functional changes (http://reviews.llvm.org/D13908).
2. Use new interfaces in SelectionDAG, while in other passes treat probabilities
as weights (http://reviews.llvm.org/D14361).
3. Use new interfaces in all other passes.
4. Remove old interfaces.
This patch is 3+4 above. In this patch, MBB won't provide weight-based
interfaces any more, which are totally replaced by probability-based ones.
The interface addSuccessor() is redesigned so that the default probability is
unknown. We allow unknown probabilities but don't allow using it together
with known probabilities in successor list. That is to say, we either have a
list of successors with all known probabilities, or all unknown
probabilities. In the latter case, we assume each successor has 1/N
probability where N is the number of successors. An assertion checks if the
user is attempting to add a successor with the disallowed mixed use as stated
above. This can help us catch many misuses.
All uses of weight-based interfaces are now updated to use probability-based
ones.
Differential revision: http://reviews.llvm.org/D14973
llvm-svn: 254348
|
|
|
|
|
|
| |
They broke a bot and I am debugging why.
llvm-svn: 254347
|
|
|
|
|
|
| |
Trying to figure out why it fails on a bot but passes locally.
llvm-svn: 254344
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We currently output FMA instructions on targets which support both FMA4 + FMA (i.e. later Bulldozer CPUS bdver2/bdver3/bdver4).
This patch flips this so FMA4 is preferred; this is for several reasons:
1 - FMA4 is non-destructive reducing the need for mov instructions.
2 - Its more straighforward to commute and fold inputs (although the recent work on FMA has reduced this difference).
3 - All supported targets have FMA4 performance equal or better to FMA - Piledriver (bdver2) in particular has half the throughput when executing FMA instructions.
Its looks like no future AMD processor lines will support FMA4 after the Bulldozer series so we're not causing problems for later CPUs.
Differential Revision: http://reviews.llvm.org/D14997
llvm-svn: 254339
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A traditional linker is roughly split in symbol resolution and "copying
stuff".
The two tasks are badly mixed in lib/Linker.
This starts splitting them apart.
With this patch there are no direct call to linkGlobalValueBody or
linkGlobalValueProto. Everything is linked via WapValue.
This also includes a few fixes:
* A GV goes undefined if the comdat is dropped (comdat11.ll).
* We error if an internal GV goes undefined (comdat13.ll).
* We don't link an unused comdat.
The first two match the behavior of an ELF linker. The second one is
equivalent to running globaldce on the input.
llvm-svn: 254336
|
|
|
|
|
|
|
|
| |
This is primarily useful for debugging optnone v. ISel issues.
Differential Revision: http://reviews.llvm.org/D14792
llvm-svn: 254335
|
|
|
|
| |
llvm-svn: 254333
|
|
|
|
| |
llvm-svn: 254332
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we know we have stack objects, we reserve the registers
that the private buffer resource and wave offset are passed
and use them directly.
If not, reserve the last 5 SGPRs just in case we need to spill.
After register allocation, try to pick the next available registers
instead of the last SGPRs, and then insert copies from the inputs
to the reserved registers in the progloue.
This also only selectively enables all of the input registers
which are really required instead of always enabling them.
llvm-svn: 254331
|
|
|
|
| |
llvm-svn: 254330
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It does not work because of emergency stack slots.
This pass was supposed to eliminate dummy registers for the
spill instructions, but the register scavenger can introduce
more during PrologEpilogInserter, so some would end up
left behind if they were needed.
The potential for spilling the scratch resource descriptor
and offset register makes doing something like this
overly complicated. Reserve registers to use for the resource
descriptor and use them directly in eliminateFrameIndex.
Also removes creating another scratch resource descriptor
when directly selecting scratch MUBUF instructions.
The choice of which registers are reserved is temporary.
For now it attempts to pick the next available registers
after the user and system SGPRs.
llvm-svn: 254329
|
|
|
|
| |
llvm-svn: 254328
|
|
|
|
|
|
| |
Fix the epilogue emission to account for that.
llvm-svn: 254325
|
|
|
|
| |
llvm-svn: 254317
|
|
|
|
|
|
|
|
|
| |
The MachineVerifier wants to check that the register operands of an
instruction belong to the instruction's register class. RIP-relative
control flow instructions violated this by referencing RIP. While this
was fixed for SysV, it was never fixed for Win64.
llvm-svn: 254315
|
|
|
|
|
|
|
|
|
|
|
| |
Re-enable shrink wrapping for PPC64 Little Endian.
One minor modification to PPCFrameLowering::findScratchRegister was necessary to handle fall-thru blocks (blocks with no terminator) correctly.
Tested with all LLVM test, clang tests, and the self-hosting build, with no problems found.
PHabricator: http://reviews.llvm.org/D14778
llvm-svn: 254314
|
|
|
|
|
|
|
| |
We were not looking past casts to see if an element should be included
or not.
llvm-svn: 254313
|
|
|
|
| |
llvm-svn: 254311
|
|
|
|
| |
llvm-svn: 254310
|
|
|
|
| |
llvm-svn: 254307
|
|
|
|
|
|
| |
This hasn't been doing anything since using relocations was added.
llvm-svn: 254304
|
|
|
|
| |
llvm-svn: 254302
|