llvm-svn: 278380

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

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

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

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

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

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

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

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

Dropped the const qualifier to match llvm::CallLowering::lowerCall

llvm-svn: 278329

The previous implementation (not custom) doesn't enforce zeroing off upper bits. The assumption is that i1 PRODUCER (truncate and extractelement) must zero all upper bits, so i1 CONSUMER instructions ( test, zext, save, etc) can be done without additional zeroing.
Make extractelement i1 lowering custom for all vector i1.

Differential Revision: http://reviews.llvm.org/D23246

llvm-svn: 278328

This patch helps avoid false dependencies on undef registers by updating the machine instructions' undef operand to use a register that the instruction is truly dependent on, or use a register with clearance higher than Pref.

Pseudo example:

loop:
xmm0 = ...
xmm1 = vcvtsi2sdl eax, xmm0<undef>
... = inst xmm0
jmp loop

In this example, selecting xmm0 as the undef register creates false dependency between loop iterations.
This false dependency cannot be solved by inserting an xor before vcvtsi2sdl because xmm0 is alive at the point of the vcvtsi2sdl instruction.
Selecting a different register instead of xmm0, especially a register that is not used in the loop, will eliminate this problem.

Differential Revision: https://reviews.llvm.org/D22466

llvm-svn: 278321

Differential Revision: http://reviews.llvm.org/D23056

llvm-svn: 278320