that complex patterns are matched after the entire pattern has
a structural match, therefore the NodeStack isn't in a useful
state when the actual call to the matcher happens.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114489 91177308-0d34-0410-b5e6-96231b3b80d8
passed the root of the match, even though only a few patterns
actually needed this (one in X86, several in ARM [which should
be refactored anyway], and some in CellSPU that I don't feel
like detangling). Instead of requiring all ComplexPatterns to
take the dead root, have targets opt into getting the root by
putting SDNPWantRoot on the ComplexPattern.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114471 91177308-0d34-0410-b5e6-96231b3b80d8
I think I've audited all uses, so it should be dependable for address spaces,
and the pointer+offset info should also be accurate when there.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114464 91177308-0d34-0410-b5e6-96231b3b80d8
instead of calling lower_bound or upper_bound directly.
This cleans up the search logic a bit because {lower,upper}_bound compare
LR->start by default, and it is usually simpler to search LR->end.
Funnelling all searches through one function also makes it possible to replace
the search algorithm with something faster than binary search.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114448 91177308-0d34-0410-b5e6-96231b3b80d8
into OptimizeCompareInstr.
This necessitates the passing of CmpValue around,
so widen the virtual functions to accomodate.
No functionality changes.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114428 91177308-0d34-0410-b5e6-96231b3b80d8
"getFixedStack" on the MachinePointerInfo class. While
this isn't the problem I'm setting out to solve, it is the
right way to eliminate PseudoSourceValue, so lets go with it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114406 91177308-0d34-0410-b5e6-96231b3b80d8
MachinePointerInfo, propagating the type out a level of API. Remove
the old MachineFunction::getMachineMemOperand impl.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114393 91177308-0d34-0410-b5e6-96231b3b80d8
MachinePointerInfo struct, no functionality change.
This also adds an assert to MachineMemOperand::MachineMemOperand
that verifies that the Value* is either null or is an IR pointer type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114389 91177308-0d34-0410-b5e6-96231b3b80d8
For now the allocator still uses the old (internal) construction mechanism by default. This will be phased out soon assuming
no issues with the builder system come up.
To invoke the new construction mechanism just pass '-regalloc=pbqp -pbqp-builder' to llc. To provide custom constraints a
Target just needs to extend PBQPBuilder and pass an instance of their derived builder to the RegAllocPBQP constructor.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114272 91177308-0d34-0410-b5e6-96231b3b80d8
more careful not to call SimplifyInstructionsInBlock() on an unreachable block, the issue has been fixed at a higher level. Add
a big warning to SimplifyInstructionsInBlock() to hopefully prevent this in the future.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114117 91177308-0d34-0410-b5e6-96231b3b80d8
that all the setup of this class currently happens at static initialization time, this misses the fact
that some later events can cause mutation of the PassRegistrationListeners list, and thus cause race issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114036 91177308-0d34-0410-b5e6-96231b3b80d8
The ELF implementation now creates text, data and bss to match the gnu as
behavior.
The text streamer still has the old MachO specific behavior since
the testsuite checks that it will error when a directive is given
before a setting the current section for example.
A nice benefit is that -n is not required anymore when producing
ELF files.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@114027 91177308-0d34-0410-b5e6-96231b3b80d8
VFP instructions use it for loading some constants, so implement that
handling.
Not thrilled with adding a member to MCOperand, but not sure there's much of
a better option that's not pretty fragile (like putting a double in the
union instead and just assuming that's good enough). Suggestions welcome...
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113996 91177308-0d34-0410-b5e6-96231b3b80d8
The problem was that the test for whether a compiler supports it or not was
inaccurate, but has to be accurate: LLVM_LOCAL_VISIBILITY is an optimization
and not needed for correctness, so wrongly thinking a compiler doesn't support
it is not a big deal, but LLVM_GLOBAL_VISIBILITY is for correctness, and not
an optimization: getting it wrong is fatal: it needs to be set based on a
configure test not testing the gcc version. Since dragonegg has moved to a
different scheme, and it was the only user of LLVM_GLOBAL_VISIBILITY, just
remove this macro.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113959 91177308-0d34-0410-b5e6-96231b3b80d8
isn't a good level of abstraction for memdep. Instead, generalize
AliasAnalysis::alias and related interfaces with a new Location
class for describing a memory location. For now, this is the same
Pointer and Size as before, plus an additional field for a TBAA tag.
Also, introduce a fixed MD_tbaa metadata tag kind.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113858 91177308-0d34-0410-b5e6-96231b3b80d8
the end of the line on a parser error, allowing skipping to happen
for syntactic errors but not for semantic errors. Before we would
miss emitting a diagnostic about the second line, because we skipped
it due to the semantic error on the first line:
foo %eax
bar %al
This fixes rdar://8414033 - llvm-mc ignores lines after an invalid instruction mnemonic errors
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113688 91177308-0d34-0410-b5e6-96231b3b80d8
the 'zero' bit down into the back-end. There are other cases where this logic
isn't sufficient, so they should be handled separately.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113665 91177308-0d34-0410-b5e6-96231b3b80d8
iterator when an optimization took place. This allows us to do more insane
things with the code than just remove an instruction or two.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113640 91177308-0d34-0410-b5e6-96231b3b80d8
(The Ada bindings probably need it too, but all the
obvious places to change say "do not edit this file".)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113618 91177308-0d34-0410-b5e6-96231b3b80d8
take multiple cycles to decode.
For the current if-converter clients (actually only ARM), the instructions that
are predicated on false are not nops. They would still take machine cycles to
decode. Micro-coded instructions such as LDM / STM can potentially take multiple
cycles to decode. If-converter should take treat them as non-micro-coded
simple instructions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113570 91177308-0d34-0410-b5e6-96231b3b80d8
is different from what the code now uses in a two ways: NamedMDNodes
were considered Values and included in the numbering, and the
function-local metadata counter wasn't reset between functions.
The later problem breaks lazy deserialization, so instead of trying
to emulate the old numbering, just drop the old metadata. The only
in-tree use case is debug info with LTO, where the QOI loss is
considered acceptable.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113557 91177308-0d34-0410-b5e6-96231b3b80d8
not unrolling loops that contain calls that would be better off getting inlined. This mostly
comes up when an interleaved devirtualization pass has devirtualized a call which the inliner
will inline on a future pass. Thus, rather than blocking all loops containing calls, add
a metric for "inline candidate calls" and block loops containing those instead.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113535 91177308-0d34-0410-b5e6-96231b3b80d8
instruction in the class would be decoded to. Or zero if the number of
uOPs must be determined dynamically.
This will be used to determine the cost-effectiveness of predicating a
micro-coded instruction.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113513 91177308-0d34-0410-b5e6-96231b3b80d8
don't use any InlineCostAnalyzer state, and are useful for other clients who don't necessarily want to use
all of InlineCostAnalyzer's logic, some of which is fairly inlining-specific.
No intended functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113499 91177308-0d34-0410-b5e6-96231b3b80d8
modules are instantiated in them. If the context is deleted, all of its owned
modules are also deleted.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113374 91177308-0d34-0410-b5e6-96231b3b80d8
AliasAnalysis, and some code for implementing the new query on top of
existing implementations by making standard alias and getModRefInfo
queries.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113329 91177308-0d34-0410-b5e6-96231b3b80d8
switch to using a ManagedStatic for the global PassRegistry instead of a
ManagedCleanup, and fix a destruction ordering bug this exposed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@113283 91177308-0d34-0410-b5e6-96231b3b80d8