Combine the logic doing the ms_abi/sysv_abi checks into one function so
that each check and its logical opposite are near each other. Now we
don't need two Sema entry points for MS va_start and regular va_start.

Refactor the code that checks if the va_start caller is a function,
block, or obj-c method. We do this in three places, and they are all
buggy for variadic lambdas (PR32737). After this change, I have one
place to apply the functional fix.

NFC

llvm-svn: 301968

llvm-svn: 301967

This patch marks a few ASan tests as unsupported on iOS. These are mostly tests that use files or paths that are invalid/inaccessible on iOS or the simulator. We currently don't have a good way of propagating/copying secondary files that individual tests need. The same problem exists on Android, so I'm just marking the tests as UNSUPPORTED now.

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

llvm-svn: 301966

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

llvm-svn: 301965

llvm-svn: 301964

handling of constexprs with unknown bounds.

This triggers a corner case of the language where it's not yet clear
whether this should be an error:

  struct A {
    static void *const a[];
    static void *const b[];
  };
  constexpr void *A::a[] = {&b[0]};
  constexpr void *A::b[] = {&a[0]};

When discovering the initializer for A::a, the bounds of A::b aren't known yet.
It is unclear whether warning about errors should be deferred until the end of
the translation unit, possibly resolving errors that can be resolved. In
practice, the compiler can know the bounds of all arrays in this example.

Credits for reproducers and explanation go to Richard Smith. Richard, please
add more info in case my explanation is wrong.

llvm-svn: 301963

I doubt anyone actually uses it, and I'm not even entirely convinced it exists
myself; but it is our default for "clang -arch armv6". Functionally, if it does
exist it's identical to the arm1176jz-f from LLVM's point of view (the
difference is apparently in the "Security Extensions").

llvm-svn: 301962

On AMDGPU if an SGPR is spilled to a VGPR, the frame index
is deleted. If there were any CSR SGPRs, this woudl
assert when setting the offset.

llvm-svn: 301961

This reverts commit r300295.

It's no longer true, print_stacktrace=1 is supported on Darwin/Windows
as of r301839.

llvm-svn: 301960

This is a follow up to the previous
inline cost patch for quicker filtering.

llvm-svn: 301959

LDS use in leaf functions not currently handled.

llvm-svn: 301958

Patch by Colin LeMahieu.

llvm-svn: 301957

Patch by Colin LeMahieu.

llvm-svn: 301956

Patch by Sid Manning.

llvm-svn: 301955

The compiler was generating code that ends up ignoring a multiple
latency dependence between two instructions by scheduling the
intructions in back-to-back packets. 

The packetizer needs to end a packet if the latency of the current
current insruction and the source in the previous packet is
greater than 1 cycle. This case occurs when there is still room in
the current packet, but scheduling the instruction causes a stall.
Instead, the packetizer should start a new packet. Also, if the
current packet already contains a stall, then it is okay to add
another instruction to the packet that also causes a stall. This
occurs when there are no instructions that can be scheduled in
between the producer and consumer instructions.

This patch changes the latency for loads to 2 cycles from 3 cycles.
This change refects that a load only needs to be separated by
one extra packet to eliminate the stall.

Patch by Ikhlas Ajbar.

llvm-svn: 301954

llvm-svn: 301953

Patch by Colin LeMahieu.

llvm-svn: 301952

Patch by Colin LeMahieu.

llvm-svn: 301951

Just let TTI's cost do this instead of arbitrarily restricting
this.

llvm-svn: 301950

Patch by Colin LeMahieu.

llvm-svn: 301949

With the forthcoming codeview::StringTable which a pdb::StringTable
would hold an instance of as one member, this ambiguity becomes
confusing.  Rename to PDBStringTable to avoid this.

llvm-svn: 301948

Patch by Colin LeMahieu.

llvm-svn: 301947

Change location number to point to conflicting branch instruction.

Patch by Colin LeMahieu.

llvm-svn: 301946

Patch by Colin LeMahieu.

llvm-svn: 301945

This reverts commit c08155afc5d3230792da2ad30a046a8617735a73.

This is causing undefined symbol errors with some of the constants.

llvm-svn: 301944

Patch by Colin LeMahieu.

llvm-svn: 301943

Instead of defining a custom iterator class, just use a function with a
callback, which is much easier to understand and less error prone.

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

llvm-svn: 301942

If all jobs complete successfully, use pool.close() instead of
pool.terminate() before waiting for the workers. Zach Turner reported
that he was getting "access denied" exceptions from pool.terminate().

Make the workers abort immediately without printing to stderr when they
are interrupted.

Finally, catch exceptions when attempting to remove our temporary
testing directory. On abnormal exit, there can often be open handles
that haven't been cleaned up yet.

llvm-svn: 301941

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

llvm-svn: 301940

  TLSDESC_ADD_LO12 relocations
Rearrange ordering in AArch64.def to follow relocation encoding
Fix name:
  R_AARCH64_P32_LD64_GOT_LO12_NC => R_AARCH64_P32_LD32_GOT_LO12_NC
Add support for several "TLS", "TLSGD", and "TLSLD" relocations for
  ILP32
Fix return values from isNonILP32reloc
Add implementations for
  R_AARCH64_ADR_PREL_PG_HI21_NC, R_AARCH64_P32_LD32_GOT_LO12_NC,
  R_AARCH64_P32_TLSIE_LD32_GOTTPREL_LO12_NC,
  R_AARCH64_P32_TLSDESC_LD32_LO12, R_AARCH64_LD64_GOT_LO12_NC,
  *TLSLD_LDST128_DTPREL_LO12, *TLSLD_LDST128_DTPREL_LO12_NC,
  *TLSLE_LDST128_TPREL_LO12, *TLSLE_LDST128_TPREL_LO12_NC
Modify error messages to give name of equivalent relocation in the
  ABI not being used, along with better checking for non-existent
  requested relocations.
Added assembler support for "pg_hi21_nc"
Relocation definitions added without implementations:
  R_AARCH64_P32_TLSDESC_ADR_PREL21, R_AARCH64_P32_TLSGD_ADR_PREL21,
  R_AARCH64_P32_TLSGD_ADD_LO12_NC, R_AARCH64_P32_TLSLD_ADR_PREL21, 
  R_AARCH64_P32_TLSLD_ADR_PAGE21, R_AARCH64_P32_TLSLD_ADD_LO12_NC,
  R_AARCH64_P32_TLSLD_LD_PREL19, R_AARCH64_P32_TLSDESC_LD_PREL19,
  R_AARCH64_P32_TLSGD_ADR_PAGE21, R_AARCH64_P32_TLS_DTPREL,
  R_AARCH64_P32_TLS_DTPMOD, R_AARCH64_P32_TLS_TPREL,
  R_AARCH64_P32_TLSDESC
Fix encoding:
  R_AARCH64_P32_TLSDESC_ADR_PAGE21

Reviewers: Peter Smith

Patch by: Joel Jones (jjones@cavium.com)

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

llvm-svn: 301939

Avoid analyzing functions multiple times. This allows
asserting that each function is only analyzed once.

llvm-svn: 301938

llvm-svn: 301937

Previously we wrote line information and file checksum
information, but we did not write information about inlinee
lines and functions.  This patch adds support for that.

llvm-svn: 301936

http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/5941

llvm-svn: 301935

It can confuse bots collecting errors.

llvm-svn: 301934

llvm-svn: 301932

Strip on OpenBSD does not correctly handle an empty .eh_frame section
and produces broken binaries in that case. Currently lld creates such
an empty .eh_frame section, despite the fact that the OpenBSD crtend.o
explicitly inserts a terminator. The Linux LSB "standard":

https://refspecs.linuxfoundation.org/LSB_5.0.0/LSB-Core-generic/LSB-Core-generic/ehframechpt.html#EHFRAME

explicitly says that

    The .eh_frame section shall contain 1 or more Call Frame Information (CFI) records.

This diff includes a test that specifically tests the issue I'm seeing
on OpenBSD.

Patch by Mark Kettenis!

llvm-svn: 301931

Reviewers: arsenm, nhaehnle

Subscribers: mehdi_amini, kzhuravl, wdng, yaxunl, dstuttard, tpr, llvm-commits, t-tye

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

llvm-svn: 301930

This was originally checked in here:
https://reviews.llvm.org/rL301923

And reverted here:
https://reviews.llvm.org/rL301924

Because there's a clang test that would fail after this. I fixed/removed the
offending CHECK lines in:
https://reviews.llvm.org/rL301928

So let's try this again. Original commit message:

This is the fold that causes the infinite loop in BoringSSL
(https://github.com/google/boringssl/blob/master/crypto/cipher/e_rc2.c)
when we fix instcombine demanded bits to prefer 'not' ops as in https://reviews.llvm.org/D32255.

There are 2 or 3 problems with dyn_castNotVal, and I don't think we can
reinstate https://reviews.llvm.org/D32255 until dyn_castNotVal is completely eliminated.

1. As shown here, it transforms 'not' into random xor. This transform is harmful to SCEV and codegen because 'not' can often be folded while random xor cannot.
2. It does not transform vector constants. This is actually a good thing, but if you don't believe the above argument, then we shouldn't have excluded vectors.
3. It tries to avoid transforming not(not(X)). That's nice, but it doesn't match the greedy nature of instcombine. If we DeMorganize a pattern that has an extra 'not' in it: ~(~(~X) & Y) --> (~X | ~Y)

  That's just another case of DeMorgan, so we should trust that we'll fold that pattern too: (~X | ~ Y) --> ~(X & Y)

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

llvm-svn: 301929

Don't test the optimizer as part of front-end verification.

llvm-svn: 301928