llvm-svn: 312593

This is a preliminary step towards solving the remaining part of PR27145 - IR for isfinite():
https://bugs.llvm.org/show_bug.cgi?id=27145

In order to solve that one more generally, we need to add matching for and/or of fcmp ord/uno
with a constant operand.

But while looking at those patterns, I realized we were missing a canonicalization for nonzero
constants. Rather than limiting to just folds for constants, we're adding a general value
tracking method for this based on an existing DAG helper.

By transforming everything to 0.0, we can simplify the existing code in foldLogicOfFCmps()
and pick up missing vector folds.

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

llvm-svn: 312591

llvm-svn: 312590

Missing these could potentially screw up post-ra scheduling.

Issue found by inspection, so I don't have a real testcase. Included
test just verifies the expected operands after expansion.

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

llvm-svn: 312589

This allows -run-pass etc. to refer to it.

(Split off from D35156.)

llvm-svn: 312587

Without this patch passing a .o file with multiple sections with the
same name to obj2yaml produces a yaml file that yaml2obj cannot
handle. This is pr34162.

The problem is that when specifying, for example, the section of a
symbol, we get only

Section: foo

and don't know which of the sections whose name is foo we have to use.

One alternative would be to use section numbers. This would work, but
the output from obj2yaml would be very inconvenient to edit as
deleting a section would invalidate all indexes.

Another alternative would be to invent a unique section id that would
exist only on yaml. This would work, but seems a bit heavy handed. We
could make the id optional and default it to the section name.

Since in the last alternative the id is basically what this patch uses
as a name, it can be implemented as a followup patch if needed.

llvm-svn: 312585

The existing code created a JITSymbol with an invalid materializer instead,
guaranteeing a 'missing symbol' error when someone tried to materialize the
symbol.

llvm-svn: 312584

S_UDT records are basically the "bridge" between the debugger's
expression evaluator and the type information. If you type
(Foo*)nullptr into the watch window, the debugger looks for an
S_UDT record named Foo. If it can find one, it displays your type.
Otherwise you get an error.

We have always understood this to mean that if you have code like
this:

  struct A {
    int X;
  };

  struct B {
    typedef A AT;
    AT Member;
  };

that you will get 3 S_UDT records. "A", "B", and "B::AT". Because
if you were to type (B::AT*)nullptr into the debugger, it would
need to find an S_UDT record named "B::AT".

But "B::AT" is actually the S_UDT record that would be generated
if B were a namespace, not a struct. So the debugger needs to be
able to distinguish this case. So what it does is:

  1. Look for an S_UDT named "B::AT". If it finds one, it knows
     that AT is in a namespace.
  2. If it doesn't find one, split at the scope resolution operator,
     and look for an S_UDT named B. If it finds one, look up the type
     for B, and then look for AT as one of its members.

With this algorithm, S_UDT records for nested typedefs are not just
unnecessary, but actually wrong!

The results of implementing this in clang are dramatic. It cuts
our /DEBUG:FASTLINK PDB sizes by more than 50%, and we go from
being ~20% larger than MSVC PDBs on average, to ~40% smaller.

It also slightly speeds up link time. We get about 10% faster
links than without this patch.

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

llvm-svn: 312583

This reverts commit r312526.

Revert "Fix test/DebugInfo/dwarfdump-decompression-invalid-size.test"

This reverts commit r312527.

It causes an ASan failure:
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/4150

llvm-svn: 312582

ld.config.txt defines linker namespaces in a way that is incompatible
with ASan. Remove the file when installing ASan on an Android O
(8.0.x) device.

Patch by Jiyong Park.

llvm-svn: 312581

Fix memory leak after r312467. The ModuleMap is the owner of the global module object until it's reparented under a real module.

llvm-svn: 312580

llvm-svn: 312579

As suggested in D37427, we could have a value tracking function and folds that use
it to simplify these cases. 

llvm-svn: 312578

Looks like raw_string_ostream is buffered. If we do not call `flush`
nor `str`, it is not guaranteed that a result string has all characters
that were written to it.

It wasn't failing on buildbots, but I could reproduce the issue on my
Windows workstation.

llvm-svn: 312577

Summary:
Check sigset_t arguments in ppoll, sig*wait*, sigprocmask
interceptors, and the entire "struct sigaction" in sigaction. This
can be done because sigemptyset/sigfullset are intercepted and
signal masks should be correctly marked as initialized.

Reviewers: vitalybuka

Subscribers: kubamracek, llvm-commits

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

llvm-svn: 312576

llvm-svn: 312575

Reviewers: dblaikie, efriedma, mehdi_amini

Reviewed By: dblaikie

Subscribers: llvm-commits

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

llvm-svn: 312574

llvm-svn: 312573

llvm-svn: 312572

llvm-svn: 312571

std::vector::insert invalidates all iterators, so it was not safe to do

  Script->Opt.Commands.insert(++I, Make(ElfSym::End1));
  Script->Opt.Commands.insert(++I, Make(ElfSym::End2));

because after the first line, `I` is no longer valid.

This patch rewrites fixes the issue. I belive the new code without
higher-order functions is a bit more readable than before.

llvm-svn: 312570

Summary:
This intrinsic represents a label with a list of associated metadata
strings. It is modelled as reading and writing inaccessible memory so
that it won't be removed as dead code. I think the intention is that the
annotation strings should appear at most once in the debug info, so I
marked it noduplicate. We are allowed to inline code with annotations as
long as we strip the annotation, but that can be done later.

Reviewers: majnemer

Subscribers: eraman, llvm-commits, hiraditya

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

llvm-svn: 312569

[SCEV] Ensure ScalarEvolution::createAddRecFromPHIWithCastsImpl properly handles out of range truncations of the start and accum values

Summary:
 When constructing the predicate P1 in ScalarEvolution::createAddRecFromPHIWithCastsImpl() it is possible
for the PHISCEV from which the predicate is constructed to be a SCEVConstant instead of a SCEVAddRec. If
this happens, then the cast<SCEVAddRec>(PHISCEV) in the code will assert.

 Such a PHISCEV is possible if either the start value or the accumulator value is a constant value
that not equal to its truncated value, and if the truncated value is zero.

 This patch adds tests that demonstrate the cast<> assertion, and fixes this problem by checking
whether the PHISCEV is a constant before constructing the P1 predicate; if it is, then P1 is
equivalent to one of P2 or P3. Additionally, if we know that the start value or accumulator
value are constants then we check whether the P2 and/or P3 predicates are known false at compile
time; if either is, then we bail out of constructing the AddRec.

Reviewers: sanjoy, mkazantsev, silviu.baranga

Reviewed By: mkazantsev

Subscribers: mkazantsev, llvm-commits

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

llvm-svn: 312568

It appears that a potential race between the cache client and the cache
pruner that I thought was unlikely actually happened in practice [1].
Try to avoid the race condition by opening the temporary file before
renaming it. Do this only on non-Windows platforms because we cannot
rename open files on Windows using the sys::fs::rename function.

[1] https://luci-logdog.appspot.com/v/?s=chromium%2Fbb%2Fchromium.memory%2FLinux_CFI%2F1610%2F%2B%2Frecipes%2Fsteps%2Fcompile%2F0%2Fstdout

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

llvm-svn: 312567

Since r312249 instructions of a entry block of region statements are
not marked as root anymore and hence can theoretically be removed
if unused. Theoretically, because the instruction list was not changed.

Still, MemoryAccesses for unused instructions were removed. This lead
to a failed assertion in the code generator  when the MemoryAccess for
the still listed instruction was not found.

This hould fix the
Assertion failed: ArrayAccess && "No array access found for instruction!",
file ScopInfo.h, line 1494
compiler crashes.

llvm-svn: 312566

Reviewers: rsmith, EricWF

Reviewed By: rsmith

Subscribers: javed.absar, cfe-commits

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

llvm-svn: 312565

We had already disabled the pattern for SSE4.1 and SSE4.2. But it got re-enabled for AVX and AVX512.

With SSE41 we rely on a separate (v4f32 (X86vzmovl VR128)) pattern to select blendps with a xorps to create zeroess. And a separate (v4f32 (scalar_to_vector FR32X)) to select a COPY_TO_REG_CLASS to move FR32 to VR128

The same thing can happen for AVX with vblendps and those separate patterns already exist.

For AVX512, (v4f32 (X86vzmov VR128)) will select a VMOVSS instruction instead of VBLENDPS due to their not being a EVEX VBLENDPS. This is what we were getting out of the larger pattern anyway. So the larger pattern is unneeded for AVX512 too.

For SSE1-SSSE3 we can rely on (v4f32 (X86vzmov VR128)) selecting a MOVSS similar to AVX512. Again this is what the larger pattern did too.

So the only real change here is that AVX1/2 now properly outputs a VBLENDPS during isel instead of a VMOVSS to match SSE41. Most tests didn't notice because the two address instruction pass knows how to turn VMOVSS into VBLENDPS to get an independent destination register.

llvm-svn: 312564

  - Refactor SIMemOpInfo's constructors
  - Allow construction of NotAtomic SIMemOpInfo

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

llvm-svn: 312563

Differential revision: https://reviews.llvm.org/D37441

llvm-svn: 312562

If the only call in a function is a tail call, the
function isn't considered to have a call since it's a
type of return.

llvm-svn: 312561

Some of the cases show missing pattern i intend to fix shortly.

llvm-svn: 312560

Commit on behalf of Graham Yiu (gyiu@ca.ibm.com)

llvm-svn: 312547

This patch changes the default behavior of `diagtool tree` to only
display warning flags and not the internal warnings flags. The latter is
an implementation detail of the compiler and usually not what the users
wants.

Furthermore, flags that are enabled by default are now also printed in
green. Originally, this was only the case for the diagnostic names.

Differential revision: https://reviews.llvm.org/D37390

llvm-svn: 312546

Precommit for https://reviews.llvm.org/D37390

llvm-svn: 312545

This prepares for https://reviews.llvm.org/D33514

llvm-svn: 312544

[AVX512] Remove patterns for (v8f32 (X86vzmovl (insert_subvector undef, (v4f32 (scalar_to_vector FR32X:)), (iPTR 0)))) and the same for v4f64.

We don't have this same pattern for AVX2 so I don't believe we should have it for AVX512. We also didn't have it for v16f32.

llvm-svn: 312543

Correct implementation:  Apparently I managed in r311683 to submit the wrong
version of the patch for this, so I'm correcting it now.

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

llvm-svn: 312542

  - Make SIMemOpInfo a class
  - Add accessor methods to SIMemOpInfo
  - Move get*Info methods to SIMemOpInfo

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

llvm-svn: 312541

  - Rename MemOpInfo -> SIMemOpInfo
  - Move SIMemOpInfo class out of SIMemoryLegalizer class

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

llvm-svn: 312540

Patch by Hansang Bae

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

llvm-svn: 312539