* Enable i386 ABI creation for freebsd
* Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap
  syscall
* Unlike linux, the last argument of mmap is actually 64-bit(off_t).
  This requires us to push an additional word for the higher order bits.
* Prior to this change, ktrace dump will show mmap failures due to
  invalid argument coming from the 6th mmap argument.

Patch by Karnajit Wangkhem

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

llvm-svn: 311002

If a variable has an explicit section such as .sdata or .sbss, it is placed
in that section and accessed in a gp relative manner. This overrides the global
-G setting.

Otherwise if a variable has a explicit section attached to it, such as '.rodata'
or '.mysection', it is not placed in the small data section. This also overrides
the global -G setting.

Reviewers: atanasyan, nitesh.jain

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

llvm-svn: 311001

It was completly unused and broke the part of the encapsulation that
common code shouldn't depend on specific plugins or language specific
features.

llvm-svn: 311000

Contributed-by: Nandini Singhal <cs15mtech01004@iith.ac.in>

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

llvm-svn: 310999

Also add a test. This fixes r310995 and PR34200.

llvm-svn: 310998

- Set the default runtime unroll count to 4 and use the newly added
  UnrollRemainder option.
- Create loop cost and force unroll for a cost less than 12.
- Disable unrolling on Thumb1 only targets.

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

llvm-svn: 310997

llvm-svn: 310996

Clang passes this options to linker. We should ignore them,
anyways they are always enabled by default atm.

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

llvm-svn: 310995

When r310905 moved the pointer and bool out of a PointerIntPair, it made
them end up uninitialized and caused UBSan failures when copying the
uninitialized boolean. However, making the pointer be null should avoid
the reference to the boolean entirely.

llvm-svn: 310994

When creating an import library from lld, the cases with
Name != ExtName shouldn't end up as a weak alias, but as a real
export of the new name, which is what actually is exported from
the DLL.

This restores the behaviour of renamed exports to what it was in
4.0.

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

llvm-svn: 310992

When creating an import library from lld, the cases with
Name != ExtName shouldn't end up as a weak alias, but as a real
export of the new name, which is what actually is exported from
the DLL.

This restores the behaviour of renamed exports to what it was in
4.0.

The other half of this commit, including test, goes into lld.

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

llvm-svn: 310991

Hook up the -k option (that in the original GNU dlltool removes the
@n suffix from the symbol that the final executable ends up linked to).

In llvm-dlltool, make sure that functions end up with the undecorate
name type if this option is set and they are decorated. In mingw, when
creating import libraries from def files instead of creating an import
library as a side effect of linking a DLL, the symbol names in the def
contain the stdcall/fastcall decoration (but no leading underscore).

By setting the undecorate name type, a linker linking to the import
library will omit the decoration from the DLL import entry.

With this in place, mingw-w64 for i386 built with llvm-dlltool/clang
produces import libraries that actually work.

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

llvm-svn: 310990

Since SVN r303491 and r304573, LLD used the COFFImportLibrary
functions from LLVM. These only had two names, Name and ExtName,
which wasn't enough to convey all the details of stdcall functions.

Stdcall functions got the wrong symbol name in the import library
itself in r303491, which is why it was reverted in r304561. When
re-landed and fixed in r304573 (after adding a test in r304572),
the symbol name itself in the import library ended up right, but the
name type of the import library entry was wrong.

This had the effect that linking to the import library succeeded
(contrary to in r303491, where linking to such an import library
failed), but at runtime, the symbol wouldn't be found in the DLL
(since the caller linked to the stdcall decorated name).

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

llvm-svn: 310989

The previous Name and ExtName aren't enough to convey all the nuances
between weak aliases and stdcall decorated function names.

A test for this will be added in LLD.

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

llvm-svn: 310988

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

llvm-svn: 310987

llvm-svn: 310986

Summary: When we move then-else code to if, we need to merge its debug info, otherwise the hoisted instruction may have inaccurate debug info attached.

Reviewers: aprantl, probinson, dblaikie, echristo, loladiro

Reviewed By: aprantl

Subscribers: sanjoy, llvm-commits

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

llvm-svn: 310985

llvm-svn: 310984

constructors when deciding whether classes should be passed indirectly.

This fixes ABI differences between Clang and GCC:

 * Previously, Clang ignored the move constructor when making this
   determination. It now takes the move constructor into account, per
   https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may
   seem recent, but the ABI change was agreed on the Itanium C++ ABI
   list a long time ago).

 * Previously, Clang's behavior when the copy constructor was deleted
   was unstable -- depending on whether the lazy declaration of the
   copy constructor had been triggered, you might get different behavior.
   We now eagerly declare the copy constructor whenever its deletedness
   is unclear, and ignore deleted copy/move constructors when looking for
   a trivial such constructor.

This also fixes an ABI difference between Clang and MSVC:

 * If the copy constructor would be implicitly deleted (but has not been
   lazily declared yet), for instance because the class has an rvalue
   reference member, we would pass it directly. We now pass such a class
   indirectly, matching MSVC.

Based on a patch by Vassil Vassilev, which was based on a patch by Bernd
Schmidt, which was based on a patch by Reid Kleckner!

This is a re-commit of r310401, which was reverted in r310464 due to ARM
failures (which should now be fixed).

llvm-svn: 310983

llvm-svn: 310982

r310940 exposed reverse-unreachable code to some optimizers,
which caused some of the code in this test to be sunk, changing
the input to the pass and breaking the exptectations.

Since that change is irrelevant to this particular test, this change
just adds an exit node to work around the problem; the
test should really be more robust (or be an MIR test?) but this preserves
the existing test intent.

llvm-svn: 310981

ReportLoopHasNoExit started failing after r310940 that added
infinite loops to postdominators. The change made regions not
contain infinite loops anymore.

This patch unbreaks the polly tree by XFAILING the
ReportLoopHasNoExit test. Full fix is under review in D36776.

llvm-svn: 310980

Undef subreg definition means that the content of the super register
doesn't matter at this point. While that's true for virtual registers,
this may not hold when replacing them with actual physical registers.
Indeed, some part of the physical register may be coalesced with the
related virtual register and thus, the values for those parts matter and
must be live.

The fix consists in checking whether or not subregs of the physical register
being assigned to an undef subreg definition are live through that def and
insert an implicit use if they are. Doing so, will keep them alive until
that point like they should be.

E.g., let vreg14 being assigned to R0_R1 then
%vreg14:gsub_0<def,read-undef> = COPY %R0 ; <-- R1 is still live here
%vreg14:gsub_1<def> = COPY %R1

Before this changes, the rewriter would change the code into:
%R0<def> = KILL %R0, %R0_R1<imp-def> ; <-- this tells R1 is redefined
%R1<def> = KILL %R1, %R0_R1<imp-def>, %R0_R1<imp-use> ; this value of this R1
                                                      ; is believed to come
                                                      ; from the previous
                                                      ; instruction

Because of this invalid liveness, later pass could make wrong choices and in
particular clobber live register as it happened with the register scavenger in
llvm.org/PR34107

Now we would generate:
%R0<def> = KILL %R0, %R0_R1<imp-def>, %R0_R1<imp-use> ; This tells R1 needs to
                                                      ; reach this point
%R1<def> = KILL %R1, %R0_R1<imp-def>, %R0_R1<imp-use>

The bug has been here forever, it got exposed recently because the register
scavenger got smarter.

Fixes llvm.org/PR34107

llvm-svn: 310979

llvm-svn: 310978

llvm-svn: 310977

llvm-svn: 310976

llvm-svn: 310974

name.

llvm-svn: 310973

Fixes a selection of rejects-valids when pack-expanding a lambda that itself
contains a pack expansion.

llvm-svn: 310972

into a function.

Most CMake configuration under compiler-rt/lib/*/tests have
almost-the-same-but-not-quite functions of the form add_X_[unit]tests
for compiling and running the tests.
Much of the logic is duplicated with minor variations across different
sub-folders.
This can harm productivity for multiple reasons:

For newcomers, resulting CMake files are very large, hard to understand,
and hide the intention of the code.
Changes for enabling certain architectures end up being unnecessarily
large, as they get duplicated across multiple folders.
Adding new sub-projects requires more effort than it should, as a
developer has to again copy-n-paste the configuration, and it's not even
clear from which sub-project it should be copy-n-pasted.
With this change the logic of compile-and-generate-a-set-of-tests is
extracted into a function, which hopefully makes writing and reading
CMake much easier.

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

llvm-svn: 310971

[InstCombine] Teach canEvaluateZExtd and canEvaluateTruncated to handle vector shifts with splat shift amount

We were only allowing ConstantInt before. This patch allows splat of ConstantInt too.

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

llvm-svn: 310970

This reverts commit r310425, thus reapplying r310335 with a fix for link
issue of the AArch64 unittests on Linux bots when BUILD_SHARED_LIBS is ON.

Original commit message:
[GlobalISel] Remove the GISelAccessor API.

Its sole purpose was to avoid spreading around ifdefs related to
building global-isel. Since r309990, GlobalISel is not optional anymore,
thus, we can get rid of this mechanism all together.

NFC.

----
The fix for the link issue consists in adding the GlobalISel library in
the list of dependencies for the AArch64 unittests. This dependency
comes from the use of AArch64Subtarget that needs to know how
to destruct the GISel related APIs when being detroyed.

Thanks to Bill Seurer and Ahmed Bougacha for helping me reproducing and
understand the problem.

llvm-svn: 310969

I can't reproduce the error that made me add this.

Reported-by: Kim Gräsman <kim.grasman@gmail.com>
Signed-off-by: Jan Vesely <jan.vesely@rutgers.edu>
Reviewed-by: Kim Gräsman <kim.grasman@gmail.com>
Reviewed-by: Aaron Watry <awatry@gmail.com>
llvm-svn: 310968

Fix for PR32763

An assert that checks if a Ref was untracked fails during ThinLTO context cleanup. The issue is because lazy loading temporary nodes didn't properly track ValueAsMetadata nodes. This patch ensures that the temporary nodes are properly tracked when they're replaced with the value.

llvm-svn: 310967

Not all targets will use -plugin with -flto. Pick a fixed target so
this works regardless of the default target (regardless of host OS,
the toolchain should be picking the correct LTO plugin for a target
that supports it).

llvm-svn: 310966

I'm explicitly ignoring the warning by casting to void instead of
deleting the local assignment, because it's confusing to see a
function that fails when its return value evaluates to true.
But when you see that it's a std::error_code, it makes more sense.

llvm-svn: 310965

the interface.

The ultimate goal here is to make it easier to do some more interesting
things in constant emission, like emit constant initializers that have
ignorable side-effects, or doing the majority of an initialization
in-place and then patching up the last few things with calls.  But for
now this is mostly just a refactoring.

llvm-svn: 310964

llvm-svn: 310963

llvm-svn: 310962

Previously, our algorithm to compute a build id involved hashing the
executable and storing that as the GUID in the CV Debug Record chunk,
and setting the age to 1.

This breaks down in one very obvious case: a user adds some newlines to
a file, rebuilds, but changes nothing else. This causes new line
information and new file checksums to get written to the PDB, meaning
that the debug info is different, but the generated code would be the
same, so we would write the same build over again with an age of 1.

Anyone using a symbol cache would have a problem now, because the
debugger would open the executable, look at the age and guid, find a
matching PDB in the symbol cache and then load it. It would never copy
the new PDB to the symbol cache.

This patch implements the canonical Windows algorithm for updating
a build id, which is to check the existing executable first, and
re-use an existing GUID while bumping the age if it already
exists.

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

llvm-svn: 310961