llvm-svn: 265437

For some reason it was hidden.

llvm-svn: 265436

Summary:
Setting this flag causes all functions are annotated with the
"nvvm-f32ftz" = "true" attribute.

In addition, we annotate the module with "nvvm-reflect-ftz" set
to 0 or 1, depending on whether -cuda-flush-denormals-to-zero is set.
This is read by the NVVMReflect pass.

Reviewers: tra, rnk

Subscribers: cfe-commits

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

llvm-svn: 265435

llvm-svn: 265434

At IR level, the swifterror argument is an input argument with type
ErrorObject**. For targets that support swifterror, we want to optimize it
to behave as an inout value with type ErrorObject*; it will be passed in a
fixed physical register.

The main idea is to track the virtual registers for each swifterror value. We
define swifterror values as AllocaInsts with swifterror attribute or a function
argument with swifterror attribute.

In SelectionDAGISel.cpp, we set up swifterror values (SwiftErrorVals) before
handling the basic blocks.

When iterating over all basic blocks in RPO, before actually visiting the basic
block, we call mergeIncomingSwiftErrors to merge incoming swifterror values when
there are multiple predecessors or to simply propagate them. There, we create a
virtual register for each swifterror value in the entry block. For predecessors
that are not yet visited, we create virtual registers to hold the swifterror
values at the end of the predecessor. The assignments are saved in
SwiftErrorWorklist and will be materialized at the end of visiting the basic
block.

When visiting a load from a swifterror value, we copy from the current virtual
register assignment. When visiting a store to a swifterror value, we create a
virtual register to hold the swifterror value and update SwiftErrorMap to
track the current virtual register assignment.

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

llvm-svn: 265433

llvm-svn: 265432

llvm-svn: 265431

llvm-svn: 265430

llvm-svn: 265426

Add no-jump-tables flag to disable use of jump tables when lowering
switch statements

Reviewers: echristo, hans

Subscribers: llvm-commits

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

llvm-svn: 265425

llvm-svn: 265424

Thanks Johannes for reminding me.

llvm-svn: 265423

Summary:
The '-p' option for dotest.py was ignored in multiprocess mode,
as the -p argument to the inferior would overwrite the -p argument
passed on the command line.

Reviewers: zturner, tfiala

Subscribers: lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265422

Summary: Flag updated in D233237

Reviewers: spyffe, jingham, Eugene.Zelenko

Subscribers: lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265421

Summary: Print environment from triple if it exists.

Reviewers: tfiala, clayborg

Subscribers: lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265420

Summary: Fixes "target list" for non-android linux platforms (ie gnu, gnueabi)

Reviewers: jasonmolenda, tfiala, clayborg, tberghammer

Subscribers: tberghammer, danalbert, lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265419

Summary:
The logic to read modules from memory was added to LoadModuleAtAddress
in the dynamic loader, but not in process gdb remote. This means that when
the remote uses svr4 packets to give library info, libraries only present
on the remote will not be loaded.

This patch therefore involves some code duplication from LoadModuleAtAddress
in the dynamic loader, but removing this would require some amount of code
refactoring.

Reviewers: ADodds, tberghammer, tfiala, deepak2427, ted

Subscribers: tfiala, lldb-commits, sas

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

Change by Francis Ricci <fjricci@fb.com>

llvm-svn: 265418

utils/update_test_checks.py was improved with:
http://reviews.llvm.org/rL265414
to CHECK-NEXT the first line of the IR function. This ensures that nothing bad
has happened before that.

llvm-svn: 265417

utils/update_test_checks.py was improved with:
http://reviews.llvm.org/rL265414
to include the first line of the function (expected to be
a comment line). This ensures that nothing bad has happened
before the first actual line of checked asm. It also matches
the existing behavior of the old script.

llvm-svn: 265416

It was broken by reshuffling induced by r265397 'Don't delete empty preheaders in CodeGenPrepare if it would create a critical edge'.

llvm-svn: 265415

We could make this an option if people don't like it. 
But since part of the reason for using a script to generate
checks is to prevent lazy checking that lets bugs crawl 
through, let's have the script check the first line too. 

For asm tests, it ensures that nothing unexpected has 
happened before the first line of asm. This matches the
existing behavior of update_llc_test_checks.py. 

More discussion in PR22897:
https://llvm.org/bugs/show_bug.cgi?id=22897

llvm-svn: 265414

llvm-svn: 265413

[TableGen] AsmMatcherEmitter.cpp: replace a sequence of "if" to "switch" in emitValidateOperandClass.

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

llvm-svn: 265412

Summary: LanaiSetflagAluCombiner could previously combine instructions across basic building blocks even when not legal. Make the LanaiSetflagAluCombiner more conservative to avoid this.

Reviewers: eliben

Subscribers: joker.eph, llvm-commits

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

llvm-svn: 265411

llvm-svn: 265410

Removed the SDNode argument passed to the AI_smul and AI_smla multiclass
definitions as they are always mul.

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

llvm-svn: 265409

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

llvm-svn: 265408

NFC.

llvm-svn: 265407

llvm-svn: 265406

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

llvm-svn: 265405

llvm-svn: 265404

This just simplifies the code a bit. More so in lld.

llvm-svn: 265403

Author: Tom Jablin (tjablin)
llvm-svn: 265402

llvm-svn: 265401

Fixing AddressSanitizer tests (update expectations for current ASan, make it work on OS X 10.10 and older).

llvm-svn: 265400

llvm-svn: 265399

Previously we had 3 different method to run shell commands on the
target and 4 copy of code waiting until a given file appears on the
target device (used for syncronization). This CL merges these methods
to 1 run_platform_command and 1 wait_for_file_on_target functions
located in some utility classes.

Differential revision: http://reviews.llvm.org/D18789

llvm-svn: 265398

Presently, CodeGenPrepare deletes all nearly empty (only phi and branch)
basic blocks. This pass can delete loop preheaders which frequently creates
critical edges. A preheader can be a convenient place to spill registers to
the stack. If the entrance to a loop body is a critical edge, then spills
may occur in the loop body rather than immediately before it. This patch
protects loop preheaders from deletion in CodeGenPrepare even if they are
nearly empty.

Since the patch alters the CFG, it affects a large number of test cases.
In most cases, the changes are merely cosmetic (basic blocks have different
names or instruction orders change slightly). I am somewhat concerned about
the test/CodeGen/Mips/brdelayslot.ll test case. If the loop preheader is not
deleted, then the MIPS backend does not take advantage of a branch delay
slot. Consequently, I would like some close review by a MIPS expert.

The patch also partially subsumes D16893 from George Burgess IV. George
correctly notes that CodeGenPrepare does not actually preserve the dominator
tree. I think the dominator tree was usually not valid when CodeGenPrepare
ran, but I am using LoopInfo to mark preheaders, so the dominator tree is
now always valid before CodeGenPrepare.

Author: Tom Jablin (tjablin)
Reviewers: hfinkel george.burgess.iv vkalintiris dsanders kbarton cycheng

http://reviews.llvm.org/D16984

llvm-svn: 265397

llvm-svn: 265396

llvm-svn: 265395