The Create method can just construct the ExecutionSession, rather than having the
client pass it in.

llvm-svn: 341872

The commit updates when AES is enabled, but failed to update the tests.
This patch fixes them.

llvm-svn: 341871

This resolves PR38875.

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

llvm-svn: 341870

Problem was that we were appending to the source location info buffer in the
copy assignment operator (instead of overwriting).

rdar://42746401

llvm-svn: 341869

llvm-svn: 341868

Mismatched braces.

llvm-svn: 341867

It's a function-like builtin, not a template.

llvm-svn: 341866

Summary:
It turns out that isPodLike isn't a good workaround for is_trivially_copyable for bit_cast's purpose. In D51872 Louis points out that tuple and pair really aren't a good fit, and for bit_cast I want to capture array. This patch instead checks is_trivially_copyable directly in bit_cast for all but GCC 4.x. In GCC 4.x developers only check for sizeof match, which means any mistake they make will succeed locally and fail on the bots. Realistically that's few developers and they'll be left behind once we upgrade past C++11.

This will allow using bit_cast with std::array.

Subscribers: dexonsmith, llvm-commits, ldionne, rsmith

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

llvm-svn: 341865

clang-format was getting confused due to the presence of a macro
invocation that was not terminated by a semicolon.  Fixed this by
terminating the macro lines with semicolons and re-ran clang-format
on the file.

llvm-svn: 341864

Although it's just a typedef, it helps for readability.  NFC.

llvm-svn: 341863

The instruction set first appeared with Westmere, but not all processors
in that and the next few generations have the instructions. According to
Wikipedia[1], the first generation in which all SKUs have AES
instructions are Skylake and Goldmont. I can't find any Skylake,
Kabylake, Kabylake-R or Cannon Lake currently listed at
https://ark.intel.com that says "Intel® AES New Instructions" "No".

This matches GCC commit
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01940.html

[1] https://en.wikipedia.org/wiki/AES_instruction_set

Patch By: thiagomacieira
Differential Revision: https://reviews.llvm.org/D51510

llvm-svn: 341862

Complements https://reviews.llvm.org/D51510 and matches
https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01940.html

GoldmontProc already has FeatureAES.

Patch By: thiagomacieira

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

llvm-svn: 341861

Summary:
_Atomic and __sync_* operations are implicitly sequentially-consistent. Some
codebases want to force explicit usage of memory order instead. This warning
allows them to know where implicit sequentially-consistent memory order is used.
The warning isn't on by default because _Atomic was purposefully designed to
have seq_cst as the default: the idea was that it's the right thing to use most
of the time. This warning allows developers who disagree to enforce explicit
usage instead.

A follow-up patch will take care of C++'s std::atomic. It'll be different enough
from this patch that I think it should be separate: for C++ the atomic
operations all have a memory order parameter (or two), but it's defaulted. I
believe this warning should trigger when the default is used, but not when
seq_cst is used explicitly (or implicitly as the failure order for cmpxchg).

<rdar://problem/28172966>

Reviewers: rjmccall

Subscribers: dexonsmith, cfe-commits

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

llvm-svn: 341860

[X86] Mark the ISD::SETLT/SETLE condition codes as illegal for v32i16/v64i8 to match the other vector types.

I'm having a hard time finding a test case for this, but we should be consistent here. The fact that we canonicalize all zeros and all ones constants to vXi32 and all other constants to loads makes this hard to hit the easy DAG combine infinite loop we get for some of the other types.

llvm-svn: 341859

deduced type (if known).

llvm-svn: 341858

This fixes building on a case sensitive filesystem with mingw-w64
headers, where all headers are lowercase. This header actually also
is named with a lowercase name in the Windows SDK as well.

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

llvm-svn: 341857

Summary: This is the only test that is still failing on Windows - or rather, it is expected to fail on the bots, but passes on the new bot that we're preparing causing a failure, so I'm going to disable it. Since the test has rarely, if ever, passed on the bots, this should have the same effect and it will unblock the creation of the new bot.

Reviewers: asmith, delcypher, zturner

Subscribers: stella.stamenova, llvm-commits

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

llvm-svn: 341856

Summary:
End goal is to update MemorySSA in all loop passes. LoopUnswitch clones all blocks in a loop. SimpleLoopUnswitch clones some blocks. LoopRotate clones some instructions.
Some of these loop passes also make CFG changes.
This is an API based on what I found needed in LoopUnswitch, SimpleLoopUnswitch, LoopRotate, LoopInstSimplify, LoopSimplifyCFG.
Adding dependent patches using this API for context.

Reviewers: george.burgess.iv, dberlin

Subscribers: sanjoy, jlebar, Prazek, llvm-commits

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

llvm-svn: 341855

Summary:
I have hit this the rough way, while trying to use this in D51870.

There is no particular point in storing the pointers, and moreover
the pointers are assumed to be non-null, and that assumption is not
enforced. If they are null, it won't be able to do anything good
with them anyway.

Initially i thought about simply adding asserts() that they are
not null, but taking/storing references looks like even cleaner solution?

Fixes [[ https://bugs.llvm.org/show_bug.cgi?id=38888 | PR38888 ]]

Reviewers: JonasToth, shuaiwang, alexfh, george.karpenkov

Reviewed By: shuaiwang

Subscribers: xazax.hun, a.sidorin, Szelethus, cfe-commits

Tags: #clang-tools-extra

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

llvm-svn: 341854

Summary: Addressed https://bugs.llvm.org/show_bug.cgi?id=38885

Subscribers: dexonsmith, llvm-commits, rsmith, steven_wu, RKSimon, Abhilash, srhines

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

llvm-svn: 341853

This is useful in certain use-cases such as D51833.

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

llvm-svn: 341852

llvm-svn: 341851

Cleanup step for D51433.

llvm-svn: 341850

Summary: An address breakpoint of the form "b 0x1000" won't resolve if it's created while the process isn't running. This patch deletes Address::SectionWasDeleted, renames Address::SectionWasDeletedPrivate to SectionWasDeleted (and makes it public), and changes the section check in Breakpoint::ModulesChanged back to its original form

Reviewers: jingham, #lldb

Reviewed By: jingham

Subscribers: davide, lldb-commits

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

llvm-svn: 341849

Summary:
- If a function is unresolved, assume it mutates its arguments
- Follow unresolved member expressions for nested mutations

Reviewers: aaron.ballman, JonasToth, george.karpenkov

Subscribers: xazax.hun, a.sidorin, cfe-commits

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

llvm-svn: 341848

This change allows usage of -march when using the clang-cl driver. This is similar to MSVC's /arch; however -march can target precisely all supported CPUs, while /arch has a more restricted set.

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

llvm-svn: 341847

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

llvm-svn: 341846

All of the ISA holes are going to make this difficult,
but we can't canonicalize the IR and try to solve PR14613
until we have backend support to get this right.

https://bugs.llvm.org/show_bug.cgi?id=14613

https://rise4fun.com/Alive/Guv
https://rise4fun.com/Alive/AADG

llvm-svn: 341845

llvm-svn: 341844

    [AMDGPU] Preliminary patch for divergence driven instruction selection. Inline immediate move to V_MADAK_F32.

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

    Reviewer: rampitec

llvm-svn: 341843

This patch removes the last reason why DIFlagBlockByrefStruct from
Clang by directly implementing the drilling into the member type done
in DwarfDebug::DbgVariable::getType() into the frontend.

rdar://problem/31629055

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

llvm-svn: 341842

The only point to this change is the test diffs.  When I remove this code entirely (in favor of the recently added generic handling), I don't want there to be any confusion due to spurious test diffs.

As an aside, the fact out tests are AST construction order dependent is not great.  I thought about fixing that, but the reasonable schemes I might want (e.g. sort by name) need the test diffs anyways.

Philip

llvm-svn: 341841

Select 32bit integer compare instructions for MIPS32.

Patch by Petar Avramovic.

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

llvm-svn: 341840

llvm-svn: 341839

Before tagging a function with coldcc make sure the target supports cold calling
convention. Without this patch HotColdSplitting pass fails on aarch64 with:

  fatal error: error in backend: Unsupported calling convention.

llvm-svn: 341838

llvm-svn: 341837

llvm-svn: 341836

LSR reassociates small constants that fit into add immediate operands as
unfolded offset. Since unfolded offset is not combined with loop-invariant
registers, LSR does not consider solutions that bump invariant registers by
these constants outside the loop.

llvm-svn: 341835

Some types and callback signatures have changed from TR6 to TR7.
Major changes (only adding signatures and stubs):
(-remove idle callback) done by D48362
-add reduction and dispatch callback
-add get_task_memory and finalize_tool runtime entry points
-ompt_invoker_t  becomes ompt_parallel_flag_t
-more types of sync_regions

Patch provided by Simon Convent

Reviewers: hbae, protze.joachim

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

llvm-svn: 341834

It is non-sensical to use cpu-specific/cpu-dispatch multiversioning
on a lambda, so prevent it when trying to add the attribute.

llvm-svn: 341833