| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 144747
|
|
|
|
|
|
| |
Devang has fixed other issues.
llvm-svn: 143003
|
|
|
|
| |
llvm-svn: 142593
|
|
|
|
| |
llvm-svn: 142592
|
|
|
|
|
|
| |
another. rdar://10293289
llvm-svn: 142234
|
|
|
|
|
|
|
|
| |
caused by r141689.
Radar 10281206.
llvm-svn: 142202
|
|
|
|
| |
llvm-svn: 141844
|
|
|
|
|
|
| |
to investigate the regressions.
llvm-svn: 141813
|
|
|
|
|
|
|
| |
containing loop's header to see if that's a landing pad. If it is, then we don't
want to hoist instructions out of the loop and above the header.
llvm-svn: 141767
|
|
|
|
|
|
|
|
|
| |
1. The speculation check may not have been performed if the BB hasn't had a load
LICM candidate.
2. If the candidate would be CSE'ed, then go ahead and speculatively LICM the
instruction even if it's in high register pressure situation.
llvm-svn: 141747
|
|
|
|
|
|
| |
Also teach MachineLICM to avoid "speculation" when register pressure is high.
llvm-svn: 141744
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The blocks with invokes have branches to the dispatch block, because that more
correctly models the behavior of the CFG. The dispatch of course has edges to
the landing pads. Those landing pads could contain invokes, which then have
branches back to the dispatch. This creates a loop. The machine LICM pass looks
at this loop and thinks it can hoist elements out of it. But because the
dispatch is an alternate entry point into the program, the hoisted instructions
won't be executed.
I wasn't able to get a testcase which was small and could reproduce all of the
time. The function_try_block.cpp in llvm-test was where this showed up.
llvm-svn: 141726
|
|
|
|
|
|
|
| |
For example, MachineLICM should not hoist a load that is not guaranteed to be executed.
Radar 10254254.
llvm-svn: 141689
|
|
|
|
| |
llvm-svn: 141594
|
|
|
|
|
|
| |
instructions.
llvm-svn: 141576
|
|
|
|
|
|
|
| |
For example, MachineLICM should not hoist a load that is not guaranteed to be executed.
Radar 10254254.
llvm-svn: 141569
|
|
|
|
|
|
| |
Sorry, I can't come up with a small test case. rdar://10043690
llvm-svn: 138934
|
|
|
|
|
|
| |
MCInstrItineraries) into MC.
llvm-svn: 134049
|
|
|
|
|
|
|
|
| |
sink them into MC layer.
- Added MCInstrInfo, which captures the tablegen generated static data. Chang
TargetInstrInfo so it's based off MCInstrInfo.
llvm-svn: 134021
|
|
|
|
| |
llvm-svn: 133944
|
|
|
|
|
|
| |
more copies. rdar://9266679
llvm-svn: 129297
|
|
|
|
| |
llvm-svn: 127175
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TargetInstrInfo:
Change produceSameValue() to take MachineRegisterInfo as an optional argument.
When in SSA form, targets can use it to make more aggressive equality analysis.
Machine LICM:
1. Eliminate isLoadFromConstantMemory, use MI.isInvariantLoad instead.
2. Fix a bug which prevent CSE of instructions which are not re-materializable.
3. Use improved form of produceSameValue.
ARM:
1. Teach ARM produceSameValue to look pass some PIC labels.
2. Look for operands from different loads of different constant pool entries
which have same values.
3. Re-implement PIC GA materialization using movw + movt. Combine the pair with
a "add pc" or "ldr [pc]" to form pseudo instructions. This makes it possible
to re-materialize the instruction, allow machine LICM to hoist the set of
instructions out of the loop and make it possible to CSE them. It's a bit
hacky, but it significantly improve code quality.
4. Some minor bug fixes as well.
With the fixes, using movw + movt to materialize GAs significantly outperform the
load from constantpool method. 186.crafty and 255.vortex improved > 20%, 254.gap
and 176.gcc ~10%.
llvm-svn: 123905
|
|
|
|
|
|
|
|
| |
These functions not longer assert when passed 0, but simply return false instead.
No functional change intended.
llvm-svn: 123155
|
|
|
|
| |
llvm-svn: 118803
|
|
|
|
|
|
| |
edges on demand.
llvm-svn: 117982
|
|
|
|
| |
llvm-svn: 117348
|
|
|
|
|
|
|
|
|
|
| |
- Initial register pressure in the loop should be all the live defs into the
loop. Not just those from loop preheader which is often empty.
- When an instruction is hoisted, update register pressure from loop preheader
to the original BB.
- Treat only use of a virtual register as kill since the code is still SSA.
llvm-svn: 116956
|
|
|
|
| |
llvm-svn: 116890
|
|
|
|
|
|
|
| |
erased the instruction during LICM so UpdateRegPressureAfter() should not
reference it afterwards.
llvm-svn: 116845
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
exposes an initializeMyPassFunction(), which
must be called in the pass's constructor. This function uses static dependency declarations to recursively initialize
the pass's dependencies.
Clients that only create passes through the createFooPass() APIs will require no changes. Clients that want to use the
CommandLine options for passes will need to manually call the appropriate initialization functions in PassInitialization.h
before parsing commandline arguments.
I have tested this with all standard configurations of clang and llvm-gcc on Darwin. It is possible that there are problems
with the static dependencies that will only be visible with non-standard options. If you encounter any crash in pass
registration/creation, please send the testcase to me directly.
llvm-svn: 116820
|
|
|
|
|
|
| |
is", which breaks some nightly tests.
llvm-svn: 116816
|
|
|
|
|
|
|
| |
in MultiSource/Benchmarks/VersaBench/beamformer/beamformer.
SmallSet.insert returns true if the element is inserted.
llvm-svn: 116790
|
|
|
|
|
|
|
|
|
|
|
| |
"long latency" enough to hoist even if it may increase spilling. Reloading
a value from spill slot is often cheaper than performing an expensive
computation in the loop. For X86, that means machine LICM will hoist
SQRT, DIV, etc. ARM will be somewhat aggressive with VFP and NEON
instructions.
- Enable register pressure aware machine LICM by default.
llvm-svn: 116781
|
|
|
|
|
|
| |
preheader to current BB and use the information determine whether hoisting is worthwhile.
llvm-svn: 116654
|
|
|
|
| |
llvm-svn: 116465
|
|
|
|
|
|
|
|
|
| |
perform initialization without static constructors AND without explicit initialization
by the client. For the moment, passes are required to initialize both their
(potential) dependencies and any passes they preserve. I hope to be able to relax
the latter requirement in the future.
llvm-svn: 116334
|
|
|
|
| |
llvm-svn: 116081
|
|
|
|
| |
llvm-svn: 115996
|
|
|
|
| |
llvm-svn: 110460
|
|
|
|
| |
llvm-svn: 110410
|
|
|
|
|
|
|
|
| |
address of the static
ID member as the sole unique type identifier. Clean up APIs related to this change.
llvm-svn: 110396
|
|
|
|
| |
llvm-svn: 109765
|
|
|
|
| |
llvm-svn: 109045
|
|
|
|
|
|
| |
threshold a bit per experimentation.
llvm-svn: 108935
|
|
|
|
|
|
|
|
|
|
| |
loop, for the reasons in the comments. This is a
major win on 253.perlbmk on ARM Darwin. I expect it
to be a good heuristic in general, but it's possible
some things will regress; I'll be watching.
7940152.
llvm-svn: 108792
|
|
|
|
|
|
| |
IMPLICIT_DEF (and subsequently eliminate them). This allows machine LICM to hoist IMPLICIT_DEF's. PR7620.
llvm-svn: 108304
|
|
|
|
|
|
|
|
| |
intended functionality change.
The avoidance of hoistiing implicitdef seems wrong though.
llvm-svn: 108109
|
|
|
|
| |
llvm-svn: 108001
|
|
|
|
|
|
|
| |
into a utility routine, teach it how to update MachineLoopInfo, and
make use of it in MachineLICM to split critical edges on demand.
llvm-svn: 106555
|