| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
|  | 
llvm-svn: 219473
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
lvi-overdefined-BB-threshold and lvi-overdefined-threshold"
Some of r218231 was reverted with the code that used it in r218971, but not all
of it. This removes the rest (which is now dead).
llvm-svn: 219469
 | 
| | 
| 
| 
|  | 
llvm-svn: 219466
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
instead
We used to transform this:
  define void @test6(i1 %cond, i8* %ptr) {
  entry:
    br i1 %cond, label %bb1, label %bb2
  bb1:
    br label %bb2
  bb2:
    %ptr.2 = phi i8* [ %ptr, %entry ], [ null, %bb1 ]
    store i8 2, i8* %ptr.2, align 8
    ret void
  }
into this:
  define void @test6(i1 %cond, i8* %ptr) {
    %ptr.2 = select i1 %cond, i8* null, i8* %ptr
    store i8 2, i8* %ptr.2, align 8
    ret void
  }
because the simplifycfg transformation into selects would happen to happen
before the simplifycfg transformation that removes unreachable control flow
(We have 'unreachable control flow' due to the store to null which is undefined
behavior).
The existing transformation that removes unreachable control flow in simplifycfg
is:
  /// If BB has an incoming value that will always trigger undefined behavior
  /// (eg. null pointer dereference), remove the branch leading here.
  static bool removeUndefIntroducingPredecessor(BasicBlock *BB)
Now we generate:
  define void @test6(i1 %cond, i8* %ptr) {
    store i8 2, i8* %ptr.2, align 8
    ret void
  }
I did not see any impact on the test-suite + externals.
rdar://18596215
llvm-svn: 219462
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This patch changes the fast-math implementation for calculating sqrt(x) from:
y = 1 / (1 / sqrt(x))
to:
y = x * (1 / sqrt(x))
This has 2 benefits: less code / faster code and one less estimate instruction 
that may lose precision.
The only target that will be affected (until http://reviews.llvm.org/D5658 is approved)
is PPC. The difference in codegen for PPC is 2 less flops for a single-precision sqrtf
or vector sqrtf and 4 less flops for a double-precision sqrt. 
We also eliminate a constant load and extra register usage.
Differential Revision: http://reviews.llvm.org/D5682
llvm-svn: 219445
 | 
| | 
| 
| 
|  | 
llvm-svn: 219444
 | 
| | 
| 
| 
|  | 
llvm-svn: 219443
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Reviewers: dblaikie
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D5688
llvm-svn: 219442
 | 
| | 
| 
| 
| 
| 
|  | 
The current implementation of GPR->FPR register moves uses a stack slot. This mechanism writes a double word and reads a word. In big-endian the load address must be displaced by 4-bytes in order to get the right value. In little endian this is no longer required. This patch fixes the issue and adds LE regression tests to fast-isel-conversion which currently expose this problem.
llvm-svn: 219441
 | 
| | 
| 
| 
|  | 
llvm-svn: 219440
 | 
| | 
| 
| 
|  | 
llvm-svn: 219437
 | 
| | 
| 
| 
|  | 
llvm-svn: 219436
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Phabricator Revision: http://reviews.llvm.org/D5674
PR21205
llvm-svn: 219434
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
long gone.
NFC.
llvm-svn: 219433
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
information.""
This reverts commit r219135 -- still causing miscompiles in SPEC it seems...
llvm-svn: 219432
 | 
| | 
| 
| 
|  | 
llvm-svn: 219429
 | 
| | 
| 
| 
| 
| 
| 
|  | 
The instruction emitter will crash if it encounters a CopyToReg
node with a non-register operand like FrameIndex.
llvm-svn: 219428
 | 
| | 
| 
| 
|  | 
llvm-svn: 219425
 | 
| | 
| 
| 
|  | 
llvm-svn: 219422
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This patch removes the PBQPBuilder class and its subclasses and replaces them
with a composable constraints class: PBQPRAConstraint. This allows constraints
that are only required for optimisation (e.g. coalescing, soft pairing) to be
mixed and matched.
This patch also introduces support for target writers to supply custom
constraints for their targets by overriding a TargetSubtargetInfo method:
std::unique_ptr<PBQPRAConstraints> getCustomPBQPConstraints() const;
This patch should have no effect on allocations.
llvm-svn: 219421
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
LLVM assumes INSERT_SUBREG will always have register operands, so
we need to legalize non-register operands, like FrameIndexes, to
avoid random assertion failures.
llvm-svn: 219420
 | 
| | 
| 
| 
|  | 
llvm-svn: 219419
 | 
| | 
| 
| 
| 
| 
|  | 
only needed there.
llvm-svn: 219418
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The VSX instruction definitions for lxsdx, lxvd2x, lxvdsx, and lxvw4x
incorrectly use the XForm_1 instruction format, rather than the
XX1Form instruction format.  This is likely a pasto when creating
these instructions, which were based on lvx and so forth.  This patch
uses the correct format.
The existing reformatting test (test/MC/PowerPC/vsx.s) missed this
because the two formats differ only in that XX1Form has an extension
to the target register field in bit 31.  The tests for these
instructions used a target register of 7, so the default of 0 in bit
31 for XForm_1 didn't expose a problem.  For register numbers 32-63
this would be noticeable.  I've changed the test to use higher
register numbers to verify my change is effective.
llvm-svn: 219416
 | 
| | 
| 
| 
|  | 
llvm-svn: 219414
 | 
| | 
| 
| 
|  | 
llvm-svn: 219413
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This introduces access to the AbstractSPDies map from DwarfDebug so
DwarfCompileUnit can access it. Eventually this'll sink down to
DwarfFile, but it'll still be generically accessible - not much
encapsulation to provide it. (constructInlinedScopeDIE could stay
further up, in DwarfFile to avoid exposing this - but I don't think
that's particularly better)
llvm-svn: 219411
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
negative values.
This patch fixes a bug in method InstCombiner::FoldCmpCstShrCst where we
wrongly computed the distance between the highest bits set of two negative
values.
This fixes PR21222.
Differential Revision: http://reviews.llvm.org/D5700
llvm-svn: 219406
 | 
| | 
| 
| 
|  | 
llvm-svn: 219401
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
While getSectionContents was updated to do the right thing,
getSectionSize wasn't.  Move the logic to getSectionSize and leverage it
from getSectionContents.
llvm-svn: 219391
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Added avx512_binop_rm_vl multiclass for VL subset
Added encoding tests
llvm-svn: 219390
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
It is not useful to return the data beyond VirtualSize it's less than
SizeOfRawData.
An implementation detail of COFF requires the section size to be rounded
up to a multiple of FileAlignment; this means that SizeOfRawData is not
representative of how large the section is.  Instead, we should cap it
to VirtualSize when this occurs as it represents the true size of the
section.
Note that this is only relevant in executable files because this
rounding doesn't occur in object files (and VirtualSize is always zero).
llvm-svn: 219388
 | 
| | 
| 
| 
| 
| 
|  | 
remove cached or unnecessary TargetMachines.
llvm-svn: 219387
 | 
| | 
| 
| 
| 
| 
| 
|  | 
These methods are already used in lots of places. This makes things more
consistent. NFC.
llvm-svn: 219386
 | 
| | 
| 
| 
|  | 
llvm-svn: 219383
 | 
| | 
| 
| 
| 
| 
| 
|  | 
the TargetMachine to a TargetSubtargetInfo since everything
we wanted is off of that.
llvm-svn: 219382
 | 
| | 
| 
| 
| 
| 
|  | 
replace them with calls off of the MachineFuncton.
llvm-svn: 219381
 | 
| | 
| 
| 
| 
| 
|  | 
the now unused TargetMachine variable.
llvm-svn: 219379
 | 
| | 
| 
| 
| 
| 
|  | 
than off the target machine.
llvm-svn: 219378
 | 
| | 
| 
| 
| 
| 
|  | 
via caching TargetLowering and using the MachineFunction.
llvm-svn: 219375
 | 
| | 
| 
| 
|  | 
llvm-svn: 219372
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
(& add a few accessors/make a couple of things public for this - it's a
bit of a toss-up, but I think I prefer it this way, keeping some more of
the meaty code down in DwarfCompileUnit - if only to make for smaller
implementation files, etc)
I think we could simplify range handling a bit if we removed the range
lists from each unit and just put a single range list on DwarfDebug,
similar to address pooling.
llvm-svn: 219370
 | 
| | 
| 
| 
|  | 
llvm-svn: 219368
 | 
| | 
| 
| 
| 
| 
|  | 
the DAG combiner.
llvm-svn: 219367
 | 
| | 
| 
| 
| 
| 
|  | 
the MachineFunction where it's already cached.
llvm-svn: 219366
 | 
| | 
| 
| 
| 
| 
|  | 
needed.
llvm-svn: 219364
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
No functional change.
This is the current AVX512_maskable multiclass hierarchy:
                 maskable_custom
                    /       \
                   /         \
          maskable_common   maskable_in_asm
            /         \
           /           \
      maskable        maskable_3src
llvm-svn: 219363
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
This adds the Pat<>'s for the intrinsics.  These are necessary because we
don't lower these intrinsics to SDNodes but match them directly.  See the
rational in the previous commit.
llvm-svn: 219362
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
These derive from the new asm-only masking definitions.
Unfortunately I wasn't able to find a ISel pattern that we could legally
generate for the masking variants.  The problem is that since the destination
is v4* we would need VK4 register classes and v4i1 value types to express the
masking.  These are however not legal types/classes in AVX512f but only in VL,
so things get complicated pretty quickly.  We can revisit this question later
if we have a more pressing need to express something like this.
So the ISel patterns are empty for the masking instructions and the next patch
will add Pat<>s instead to match the intrinsics calls with instructions.
llvm-svn: 219361
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
No functional change.
No change in X86.td.expanded except for the appearance of the new attributes.
The new attributes will be used in the subsequent patch.
llvm-svn: 219360
 |