| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
A version of 0x1000 is 0.16.0, not 1.0.0 as the comment said. Fix the
value to match the comment, and also the one test case which had this
wrong.
llvm-svn: 278381
|
| |
|
|
| |
llvm-svn: 278380
|
| |
|
|
|
|
|
|
|
|
| |
Follow-up from r278264 after Joerg's feedback.
Since bzero is not standard, be more strict: also check if the first
argument is a pointer, which harden the check for when it does not come
originally from a builtin.
llvm-svn: 278379
|
| |
|
|
|
|
|
|
| |
Patch by Sunita Marathe
Differential Revision: https://reviews.llvm.org/D21449
llvm-svn: 278378
|
| |
|
|
|
|
|
|
| |
This adds a createFunctionInliningPass pass that takes an InlineParams object and use this to create the pre-inliner pass. This prevents the regular inliner's threshold flag from influencing the preinliner.
Differential revision: https://reviews.llvm.org/D23377
llvm-svn: 278377
|
| |
|
|
|
|
|
|
|
|
| |
From the point of view of register assignment, byval parameters are
ignored: a byval parameter is not going to be assigned to a register,
and it will not affect the assignments of subsequent parameters.
When matching registers with parameters in the bit tracker, make sure
to skip byval parameters before advancing the registers.
llvm-svn: 278375
|
| |
|
|
| |
llvm-svn: 278373
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
An upcoming commit will change how we choose to reference a dylib. Currently
dylibs are only given an LC_LOAD_DYLIB in the final image if an atom is used.
This is different from ld64 which adds the load command when the dylib is referenced
on the cmdline.
In order to change this behaviour, we need libSystem.yaml to actually contain a mach header
so that it is parsed as a dylib, instead of currently being parsed as a normalised file.
To get a mach header, we also require an arch, so now we have one libsystem per arch and
all the tests have been updated to choose the correct one.
llvm-svn: 278372
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: Some backends, like WebAssembly, use virtual registers instead of physical registers. This crashes the DbgValueHistoryCalculator pass, which assumes that all registers are physical. Instead, skip virtual registers when iterating aliases, and assume that they are clobbered.
Reviewers: dexonsmith, dschuff, aprantl
Subscribers: yurydelendik, llvm-commits, jfb, sunfish
Differential Revision: https://reviews.llvm.org/D22590
llvm-svn: 278371
|
| |
|
|
|
|
|
|
| |
This fixes PR28824.
Differential Revision: https://reviews.llvm.org/D23220
llvm-svn: 278370
|
| |
|
|
| |
llvm-svn: 278369
|
| |
|
|
|
|
|
|
|
| |
Factor out some common logic used to find the runtime library in a list
of modules.
Differential Revision: https://reviews.llvm.org/D23150
llvm-svn: 278368
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adapters for instrumentation runtimes have to do two basic things:
1) Load a runtime library.
2) Install breakpoints in that library.
This logic is duplicated in the adapters for asan and tsan. Factor it
out and document bits of it to make it easier to add new adapters.
I tested this with check-lldb, and double-checked
testcases/functionalities/{a,t}san.
Differential Revision: https://reviews.llvm.org/D23043
llvm-svn: 278367
|
| |
|
|
| |
llvm-svn: 278366
|
| |
|
|
|
|
|
|
| |
Deletes unused remove() and containsPointer() interfaces. NFC.
Differential Revision: https://reviews.llvm.org/D23360
llvm-svn: 278365
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D23291
llvm-svn: 278364
|
| |
|
|
|
|
|
| |
Try to appease MSVC bot:
http://lab.llvm.org:8011/builders/sanitizer-windows/builds/27164/steps/run%20tests/logs/stdio
llvm-svn: 278363
|
| |
|
|
|
|
|
| |
This was kind of confusing, the subregister
class shouldn't really be necessary.
llvm-svn: 278362
|
| |
|
|
| |
llvm-svn: 278361
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23133
llvm-svn: 278360
|
| |
|
|
| |
llvm-svn: 278359
|
| |
|
|
| |
llvm-svn: 278358
|
| |
|
|
|
|
|
|
|
| |
Some filesystems track atime always. This relaxes the test to accept either a
filesystem which does not accurately track atime or does track the atime
accurately. This allows the test to pass on filesystems mounted with
`strictatime` on Linux or on macOS.
llvm-svn: 278357
|
| |
|
|
|
|
|
|
|
|
|
|
| |
basic_string's constructor calls init which was not getting inlined. This
prevented optimization of const string as init would appear as a call in between
a string's def and use.
Patch by Laxman Sole and Aditya Kumar.
Differential Revision: https://reviews.llvm.org/D22782
llvm-svn: 278356
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Check for end() before skipping through debug values. This avoids
dereferencing end() when the instruction is the final one in the basic
block. (It still assumes that a debug value will not be the final
instruction in the basic block. No tests seemed to violate that.)
Many Hexagon tests trigger this, but they happen to magically pass right
now. I found this because WIP patches for PR26753 convert them into
crashes.
llvm-svn: 278355
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23133
llvm-svn: 278354
|
| |
|
|
|
|
|
|
|
|
| |
There are still a few missing symbols reported by:
http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/15535/steps/build_llvmclang/logs/stdio
http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/15535/steps/build_llvmclang/logs/stdio
This should hopefully take care of them.
llvm-svn: 278353
|
| |
|
|
| |
llvm-svn: 278352
|
| |
|
|
|
|
|
| |
Otherwise we only materialize (shared) constants in the first function they
appear in. This doesn't go well.
llvm-svn: 278351
|
| |
|
|
|
|
|
|
|
| |
After machine block placement, MBBs may not have terminators, and it is
appropriate to check for the end iterator here. We can fold the check
into the next if, as well. This look is really just looking for BBs that
end in CATCHRET.
llvm-svn: 278350
|
| |
|
|
|
|
| |
Follow-on to r278341: Update CMakeLists.txt to match LLVMBuild.txt
llvm-svn: 278349
|
| |
|
|
|
|
|
|
|
|
| |
ExecutionEngine::runFunction is supposed to allow execution of arbitrary
function types, but MCJIT can only reasonably support a limited subset of
main-linke function types. This patch documents this limitation, and fixes
MCJIT::runFunction to abort with a meaningful error at runtime if called with
an unsupported function type.
llvm-svn: 278348
|
| |
|
|
|
|
|
| |
Avoid relying on the MachineInstrBundleIterator operator== being
implemented as a member function.
llvm-svn: 278347
|
| |
|
|
|
|
|
|
|
|
|
| |
End iterators are usually sentinels, not actually Instruction* at all.
Stop casting to it just to get an iterator back.
There is likely no observable functionality change here right now
(although this is relying on UB, I doubt it was triggering anything),
but I'll be removing the cast soon.
llvm-svn: 278346
|
| |
|
|
|
|
| |
Python headers need to be included before PosixApi.h
llvm-svn: 278345
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Check for an end iterator from MachineBasicBlock::getFirstTerminator in
llvm::getFuncletMembership. If this is turned into an assertion, it
fires in 48 X86 testcases (for example,
CodeGen/X86/regalloc-spill-at-ehpad.ll).
Since this is likely a latent bug (shouldn't all basic blocks end with a
terminator?) I've filed PR28938.
llvm-svn: 278344
|
| |
|
|
| |
llvm-svn: 278343
|
| |
|
|
| |
llvm-svn: 278342
|
| |
|
|
|
|
|
|
| |
Add some missing dependences to the llvm-lto2 tool to attempt to appease
missing symbols in link from bot:
http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/15527
llvm-svn: 278341
|
| |
|
|
| |
llvm-svn: 278340
|
| |
|
|
| |
llvm-svn: 278339
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This restores commit r278330, with fixes for a few bot failures:
- Fix a late change I had made to the save temps output file that I
missed due to existing files sitting on my disk
- Fix a bunch of Windows bot failures with "ambiguous call to overloaded
function" due to confusion between llvm::make_unique vs
std::make_unique (preface the new make_unique calls with "llvm::")
- Attempt to fix a modules bot failure by adding a missing include
to LTO/Config.h.
Original change:
Resolution-based LTO API.
Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol in each object, rather than the combined object as a whole. This will
become increasingly important for use cases such as ThinLTO which require us
to process symbol resolutions in a more complicated way than just adjusting
linkage.
Patch by Peter Collingbourne.
Reviewers: rafael, tejohnson, mehdi_amini
Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D20268
llvm-svn: 278338
|
| |
|
|
| |
llvm-svn: 278337
|
| |
|
|
|
|
| |
This reverts revision 278333, newly added test failed.
llvm-svn: 278336
|
| |
|
|
|
|
| |
This makes lldb still compile on linux after a project-wide clang-format
llvm-svn: 278335
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When legal, extending trip count in the loop control logic generates better code compared to truncating IV. This is because
(1) extending trip count is a loop invariant operation (see genLoopLimit where we prove trip count is loop invariant).
(2) Scalar Evolution seems to have problems understanding trunc when computing loop trip count. So removing them allows better analysis performed in Scalar Evolution. (In particular this fixes PR 28363 which is the motivation for this change).
I am not going to perform any performance test. Any degradation caused by this should be an indication of a bug elsewhere.
To prove legality, we rely on SCEV to prove zext(trunc(IV)) == IV (or similarly for sext). If this holds, we can prove equivalence of trunc(IV)==ExitCnt (1) and IV == zext(ExitCnt). Simply take zext of boths sides of (1) and apply the proven equivalence.
https://reviews.llvm.org/D23075
llvm-svn: 278334
|
| |
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D23323
llvm-svn: 278333
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D23175
llvm-svn: 278332
|
| |
|
|
|
|
|
|
|
|
| |
This reverts commit r278330.
I made a change to the save temps output that is causing issues with the
bots. Didn't realize this because I had older output files sitting on
disk in my test output directory.
llvm-svn: 278331
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This introduces a resolution-based LTO API. The main advantage of this API over
existing APIs is that it allows the linker to supply a resolution for each
symbol in each object, rather than the combined object as a whole. This will
become increasingly important for use cases such as ThinLTO which require us
to process symbol resolutions in a more complicated way than just adjusting
linkage.
Patch by Peter Collingbourne.
Reviewers: rafael, tejohnson, mehdi_amini
Subscribers: lhames, tejohnson, mehdi_amini, llvm-commits
Differential Revision: https://reviews.llvm.org/D20268
Address review comments
llvm-svn: 278330
|