| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
|
|
| |
When expanding a truncating store or extending load using vector extracts or
inserts and scalar stores and loads, we were giving each of these scalar stores
or loads the same alignment as the original vector operation. While this will
often be right (most vector operations, especially those produced by
autovectorization, have the alignment of the underlying scalar type), the
vector operation could certainly have a larger alignment.
No test case (yet); noticed by inspection.
llvm-svn: 230175
|
| |
|
|
| |
llvm-svn: 230170
|
| |
|
|
|
|
| |
LLVM_ATTRIBUTE_UNUSED. [-Wunused-function]
llvm-svn: 230169
|
| |
|
|
| |
llvm-svn: 230168
|
| |
|
|
|
|
| |
\param should be used as itemized.
llvm-svn: 230167
|
| |
|
|
| |
llvm-svn: 230165
|
| |
|
|
|
|
|
| |
The CodeView debug info section, .debug$S, also has this set. MinGW
sets this bit for their DWARF sections as well.
llvm-svn: 230156
|
| |
|
|
| |
llvm-svn: 230155
|
| |
|
|
| |
llvm-svn: 230154
|
| |
|
|
| |
llvm-svn: 230153
|
| |
|
|
|
|
|
|
|
|
| |
work with a non-canonical induction variable.
This is currently a non-functional change because we only ever call
computeSafeIterationSpace on a canonical induction variable; but the
generalization will be useful in a later commit.
llvm-svn: 230151
|
| |
|
|
|
|
|
|
|
| |
calculations. Semantically non-functional change.
This gets rid of some of the SCEV -> Value -> SCEV round tripping and
the Construct(SMin|SMax)Of and MaybeSimplify helper routines.
llvm-svn: 230150
|
| |
|
|
| |
llvm-svn: 230149
|
| |
|
|
|
|
|
| |
This is a code size optimization when the constant
only has one use.
llvm-svn: 230148
|
| |
|
|
| |
llvm-svn: 230147
|
| |
|
|
| |
llvm-svn: 230146
|
| |
|
|
|
|
| |
NFC.
llvm-svn: 230143
|
| |
|
|
| |
llvm-svn: 230142
|
| |
|
|
|
|
|
| |
While it's not POD due to the user-defined constructor, it's still a trivially
copyable type. No functional change.
llvm-svn: 230141
|
| |
|
|
| |
llvm-svn: 230137
|
| |
|
|
|
|
|
| |
This was just replicating logic from the legalizer. Covered by existing
tests.
llvm-svn: 230136
|
| |
|
|
|
|
|
|
| |
asm parsing since it's not subtarget dependent and we can't depend
upon the one hanging off the MachineFunction's subtarget still
being around.
llvm-svn: 230135
|
| |
|
|
| |
llvm-svn: 230134
|
| |
|
|
|
|
|
| |
MCSubtargetInfo as the MachineFunction has gone away and we need
to emit code at the module level.
llvm-svn: 230133
|
| |
|
|
| |
llvm-svn: 230132
|
| |
|
|
|
|
| |
have. Also, the subtarget is invalid at this point.
llvm-svn: 230131
|
| |
|
|
|
|
|
|
| |
Synthesizing a call directly using the MI layer would confuse the frame
lowering code. This is problematic as frame lowering is highly
sensitive the particularities of calls, etc.
llvm-svn: 230129
|
| |
|
|
|
|
| |
This adds section group support to the tools obj2yaml and yaml2obj.
llvm-svn: 230124
|
| |
|
|
|
|
| |
Pointed out by David Majnemer.
llvm-svn: 230122
|
| |
|
|
|
|
|
|
|
|
|
| |
Everyone except R600 was manually passing the length of a static array
at each callsite, calculated in a variety of interesting ways. Far
easier to let ArrayRef handle that.
There should be no functional change, but out of tree targets may have
to tweak their calls as with these examples.
llvm-svn: 230118
|
| |
|
|
|
|
|
|
|
|
| |
Stack realignment occurs after the prolog, not during, for Win64.
Because of this, don't factor in the maximum stack alignment when
establishing a frame pointer.
This fixes PR22572.
llvm-svn: 230113
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Parse (and write) symbolic constants in debug info `flags:` fields.
This prevents a readability (and CHECK-ability) regression with the new
debug info hierarchy.
Old (well, current) assembly, with pretty-printing:
!{!"...\\0016387", ...} ; ... [public] [rvalue reference]
Flags field without this change:
!MDDerivedType(flags: 16387, ...)
Flags field with this change:
!MDDerivedType(flags: DIFlagPublic | DIFlagRValueReference, ...)
As discussed in the review thread, this isn't a final state. Most of
these flags correspond to `DW_AT_` symbolic constants, and we might
eventually want to support arbitrary attributes in some form. However,
as it stands now, some of the flags correspond to other concepts (like
`FlagStaticMember`); until things are refactored this is the simplest
way to move forward without regressing assembly.
llvm-svn: 230111
|
| |
|
|
|
|
|
|
| |
Split debug info 'flags' bitfield over a vector so the current flags can
be iterated over. This API (in combination with r230107) will be used
for assembly support for symbolic constants.
llvm-svn: 230108
|
| |
|
|
|
|
|
|
|
| |
Add `DIDescriptor::getFlag(StringRef)` and
`DIDescriptor::getFlagString(unsigned)`. The latter only converts exact
matches; I'll add separate API for breaking the flags bitfield up into
parts.
llvm-svn: 230107
|
| |
|
|
|
|
|
|
| |
Leverage `StringRef` inside keyword comparison macros. There's no
reason to be so low-level here, and I'm about to add another
`startswith()` use, so let's make it easy to read.
llvm-svn: 230100
|
| |
|
|
|
|
|
|
| |
configurable per GC
Previously, this pass ran over every function in the Module if added to the pass order. With this change, it runs only over those with a GC attribute where the GC explicitly opts in. A GC can also choose which of entry safepoint polls, backedge safepoint polls, and call safepoints it wants. I hope to get these exposed as checks on the GCStrategy at some point, but for now, the checks are manual string comparisons.
llvm-svn: 230097
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
`do { ... } while (false)` is standard macro etiquette for forcing
instantiations into a single statement and requiring a `;` afterwards,
making statement-like macros easier to reason about (and harder to use
incorrectly).
I'm about to modify the macros in `LexIdentifier()`. I noticed that the
`KEYWORD` macro *does* follow the rule, so I thought I'd clean up the
other macros to match (otherwise might not be worth changing, since the
benefits of this pattern are fairly irrelevant here).
llvm-svn: 230095
|
| |
|
|
|
|
|
| |
Also simplify some else-after-return cases including some standard
algorithm convenience/use.
llvm-svn: 230094
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Letting them begin at the PHI instruction slightly simplifies the code
but more importantly avoids breaking the assumption that live ranges
starting at the block begin are also live at the end of the predecessor
blocks. The MachineVerifier checks that but was apparently never run in
the few instances where liveranges are calculated for machine-SSA
functions.
Reviewers: qcolombet
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D7779
llvm-svn: 230093
|
| |
|
|
|
|
| |
These are internal options. I need to go through, evaluate which are worth keeping and which not. Many of them should probably be renamed as well. Until I have time to do that, we can at least stop poluting the standard opt -help output.
llvm-svn: 230088
|
| |
|
|
|
|
| |
Also refactor code to remove some duplication.
llvm-svn: 230087
|
| |
|
|
|
|
| |
This should be the last cleanup on non-llvm preferred data structures. I left one use of std::set in an assertion; DenseSet didn't seem to have a tombstone for CallSite defined. That might be worth fixing, but wasn't worth it for a debug only use.
llvm-svn: 230084
|
| |
|
|
|
|
| |
I'd done the work of extracting the typedef in a previous commit, but didn't actually change it. Hopefully this will make any subtle changes easier to isolate.
llvm-svn: 230081
|
| |
|
|
|
|
| |
Migrate std::vector usage to a combination of SmallVector and ArrayRef.
llvm-svn: 230079
|
| |
|
|
| |
llvm-svn: 230078
|
| |
|
|
| |
llvm-svn: 230075
|
| |
|
|
| |
llvm-svn: 230074
|
| |
|
|
|
|
|
|
|
|
| |
The expansion code does the same thing. Since
the operands were not defined with the correct
types, this has the side effect of fixing operand
folding since the expanded pseudo would never use
SGPRs or inline immediates.
llvm-svn: 230072
|
| |
|
|
|
|
|
|
|
|
|
| |
This enables a few useful combines that used to only
use fma.
Also since v_mad_f32 apparently does not support denormals,
disable the existing cases that are custom handled if they are
requested.
llvm-svn: 230071
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows sharing of FMA forming combines to work
with instructions that have the same semantics as a separate
multiply and add.
This is expand by default, and only formed post legalization
so it shouldn't have much impact on targets that do not want it.
llvm-svn: 230070
|