| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
MFHI, MFLO, MTHI and MTLO instructions
Differential Revision: http://reviews.llvm.org/D14436
llvm-svn: 254297
|
| |
|
|
|
|
|
| |
Value of offset operand for microMIPS BALC and BC instructions is currently shifted 2 bits, but it should be 1 bit.
Differential Revision: http://reviews.llvm.org/D14770
llvm-svn: 254296
|
| |
|
|
|
|
|
|
| |
PRECRQ.QB.PH, PRECRQU_S.QB.PH and PRECRQ_RS.PH.W instructions
Differential Revision: http://reviews.llvm.org/D14605
llvm-svn: 254291
|
| |
|
|
|
|
| |
build bot.
llvm-svn: 254280
|
| |
|
|
| |
llvm-svn: 254279
|
| |
|
|
|
|
|
|
| |
vector. This is reflected correctly in the intrinsics, but was not refelected in the isel patterns.
For the floating point types, this requires adding a bitcast to the index vector when its passed through to the output.
llvm-svn: 254277
|
| |
|
|
|
|
| |
The lambda is more readable.
llvm-svn: 254276
|
| |
|
|
| |
llvm-svn: 254275
|
| |
|
|
|
|
| |
verify there are no others.
llvm-svn: 254274
|
| |
|
|
| |
llvm-svn: 254272
|
| |
|
|
| |
llvm-svn: 254271
|
| |
|
|
|
|
| |
for its shuffle indices.
llvm-svn: 254269
|
| |
|
|
| |
llvm-svn: 254268
|
| |
|
|
| |
llvm-svn: 254267
|
| |
|
|
| |
llvm-svn: 254266
|
| |
|
|
| |
llvm-svn: 254265
|
| |
|
|
| |
llvm-svn: 254264
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This one is enabled only under -ffast-math. There are cases where the
difference between the value computed and the correct value is huge
even for ffast-math, e.g. as Steven pointed out:
x = -1, y = -4
log(pow(-1), 4) = 0
4*log(-1) = NaN
I checked what GCC does and apparently they do the same optimization
(which result in the dramatic difference). Future work might try to
make this (slightly) less worse.
Differential Revision: http://reviews.llvm.org/D14400
llvm-svn: 254263
|
| |
|
|
|
|
|
|
| |
This fixes buildbots in systems that std::to_string is not present. It
also tidies the output of the diagnostic to render doubles a bit better
(thanks Ben Kramer for help with string streams and format).
llvm-svn: 254261
|
| |
|
|
| |
llvm-svn: 254260
|
| |
|
|
|
|
| |
We could already recognise shuffle(FSUB, FADD) -> ADDSUB, this allow us to recognise shuffle(FADD, FSUB) -> ADDSUB by commuting the shuffle mask prior to matching.
llvm-svn: 254259
|
| |
|
|
| |
llvm-svn: 254254
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D14810
llvm-svn: 254248
|
| |
|
|
| |
llvm-svn: 254246
|
| |
|
|
| |
llvm-svn: 254243
|
| |
|
|
| |
llvm-svn: 254242
|
| |
|
|
|
|
|
| |
We were not handling the case where an entry must be dropped and the
destination module has no llvm.global_ctors.
llvm-svn: 254241
|
| |
|
|
|
|
|
| |
Playing with mutateType in here was making getValueType and getType
incompatible.
llvm-svn: 254240
|
| |
|
|
| |
llvm-svn: 254239
|
| |
|
|
|
|
|
|
| |
memory read below.
Found by msan!
llvm-svn: 254238
|
| |
|
|
|
|
|
|
|
|
| |
This is the last step to enable profile runtime to share the same value prof
data format and reader/writer code with llvm host tools. The VP related
data structures are moved to a section in InstrProfData.inc enabled with macro
INSTR_PROF_VALUE_PROF_DATA, and common API implementations are enabled with
INSTR_PROF_COMMON_API_IMPL. There should be no functional change.
llvm-svn: 254235
|
| |
|
|
|
|
|
|
|
| |
in the ARM ARM."
This reverts commit r254201 and r254202, as it broke test-suite,
self-hosting and sanitizer tests on ARM buildbots.
llvm-svn: 254234
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements dynamic realignment of stack objects for targets
with a non-realigned stack pointer. Behaviour in FunctionLoweringInfo
is changed so that for a target that has StackRealignable set to
false, over-aligned static allocas are considered to be variable-sized
objects and are handled with DYNAMIC_STACKALLOC nodes.
It would be good to group aligned allocas into a single big alloca as
an optimization, but this is yet todo.
SystemZ benefits from this, due to its stack frame layout.
New tests SystemZ/alloca-03.ll for aligned allocas, and
SystemZ/alloca-04.ll for "no-realign-stack" attribute on functions.
Review and help from Ulrich Weigand and Hal Finkel.
llvm-svn: 254227
|
| |
|
|
| |
llvm-svn: 254222
|
| |
|
|
| |
llvm-svn: 254220
|
| |
|
|
|
|
|
|
|
| |
Raw profile writer needs to write all data of one kind in one continuous block,
so the buffer needs to be pre-allocated and passed to the writer method in
pieces for function profile data. The change adds the support for raw value data
writing.
llvm-svn: 254219
|
| |
|
|
| |
llvm-svn: 254218
|
| |
|
|
| |
llvm-svn: 254217
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds two thresholds to the sample profiler to affect inlining
decisions: the concept of global hotness and coldness.
Functions that have accumulated more than a certain fraction of samples at
runtime, are annotated with the InlineHint attribute. Conversely,
functions that accumulate less than a certain fraction of samples, are
annotated with the Cold attribute.
This is very similar to the hints emitted by Clang when using
instrumentation profiles.
Notice that this is a very blunt instrument. A function may have
globally collected a significant fraction of samples, but that does not
necessarily mean that every callsite for that function is hot.
Ideally, we would annotate each callsite with the samples collected at
that callsite. This way, the inliner can incorporate all these weights
into its cost model.
Once the inliner offers this functionality, we can change the hints
emitted here to a more precise per-callsite annotation. For now, this is
providing some measure of speedups with our internal benchmarks. I've
observed speedups of up to 23% (though the geo mean is about 3%). I expect
these numbers to improve as the inliner gets better annotations.
llvm-svn: 254212
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Based on testing of internal benchmarks, I'm lowering this threshold to
a value of 0.1%. This means that SamplePGO will respect 99.9% of the
original inline decisions when following a profile.
The performance difference is noticeable in some tests. With the
previous threshold, the speedups over baseline -O2 was about 0.63%. With
the new default, the speedups are around 3% on average.
The point of this threshold is not to do more aggressive inlining. When
an inlined callsite crosses this threshold, SamplePGO will redo the
inline decision so that it can better apply the input profile.
By respecting most original inline decisions, we can apply more of the
input profile because the shape of the code follows the profile more
closely.
In the next series, I'll be looking at adding some inline hints for the
cold callsites and for toplevel functions that are hot/cold as well.
llvm-svn: 254211
|
| |
|
|
|
|
|
|
| |
Now the ValueMapper has two callbacks. The first one maps the
declaration. The ValueMapper records the mapping and then materializes
the body/initializer.
llvm-svn: 254209
|
| |
|
|
| |
llvm-svn: 254202
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ARM ARM.
Summary:
Since this build attribute corresponds to a whole module, and
different functions in a module may differ in the optimizations
enabled for them, this attribute is emitted after all functions,
and only in the case that the optimization goals for all
functions match.
Reviewers: logan, hans
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: http://reviews.llvm.org/D14934
llvm-svn: 254201
|