It retains the possibility to use the autoconf build with a
command-line option ('-use-autoconf'), and uses that by default on Darwin since
compiler-rt requires it on that platform.
This commit also removes the "Release-64" flavour and related logic. The script
would previously do two builds unless the '-no-64bit' flag was passed, but on
my machine and from those I asked this always ended up producing two 64-bit builds,
causing much confusion.
It also removes the -build-triple option, which caused the --build= flag to
get passed to ./configure. This was presumably intended for cross-compiling,
but none of the release testers use it. If someone does want to pass it,
they can use '-configure-flags --build=foo' instead.
Differential Revision: http://reviews.llvm.org/D10715
llvm-svn: 242331
Summary:
This patch allows phi nodes like
%x = phi [ %incptr, ... ] [ %var, ... ]
%incptr = getelementptr %x, 1
to be analyzed by BasicAliasAnalysis.
In aliasPHI, we can detect incoming values that are recursive GEPs with a
constant offset. Instead of trying to analyze a recursive GEP (and failing),
we now ignore it and instead set the size of the memory referenced by
the PHINode to UnknownSize. This represents all the possible memory
locations the pointer represented by the PHINode could be advanced to
by the GEP.
For now, this new behavior is turned off by default to allow debugging of
performance degradations seen with SPEC/x86 and Hexagon benchmarks.
The flag -basicaa-recphi turns it on.
Reviewers: hfinkel, sanjoy
Subscribers: tobiasvk_caf, sanjoy, llvm-commits
Differential Revision: http://reviews.llvm.org/D10368
llvm-svn: 242320
Summary:
The accept4 syscall is missing on older ARM Android kernels, and the accept()
call is implemented with the accept4 syscall, so we'll need to call the accept
syscall directly.
Reviewers: vharron, tberghammer, labath
Subscribers: ovyalov, chaoren, labath, tberghammer, aemerson, lldb-commits
Differential Revision: http://reviews.llvm.org/D10887
llvm-svn: 242319
This helps with freeform documentation styles, where otherwise code like
enum class E {
E1, // D1
E2 // D2
};
would result in D1 being associated with E2. To properly associate E1
with D1 and E2 with D2, this patch allows all raw comments C such that
C.isParseAllComments() to participate in trailing comment checks inside
getRawCommentForDeclNoCache. This takes care of linking the intended
documentation with the intended decls. There remains an issue with code
like:
foo(); // DN
int x;
To prevent DN from being associated with x, this patch adds a new test
on preceding-line comments C (where C.isParseAllComments() and also
C's kind is RCK_OrdinaryBCPL or RCK_OrdinaryC) that checks whether C
is the first non-whitespace thing on C's starting line.
Patch from Luke Zarko <zarko@google.com>, D11069 reviewed by rsmith.
llvm-svn: 242317
Revision 224297 modified the behavior of vec_sld for little endian so
that LLVM will generate the correct corresponding vsldoi instruction.
I neglected to update the existing tests, which continued to pass
because they were not specific enough. This patch adds enough
specificity to the tests to make them useful for BE and LE testing of
vec_sld.
llvm-svn: 242313
is true on MSYS bash although this requires: used to disable tests on MSYS bash.
Nevertheless, all tests requiring shell-preserves-root do pass except for
Driver/darwin-sdkroot.c. It will require a patch, either by disabling it on
Windows or by fixing shell-preserves-root to really be true only on MSYS
and making darwin-sdkroot.c its only user.
In any case, all other tests requiring shell-preserves-root do not really require
it so I'm replacing REQUIRES: shell-preserves-root with REQUIRES: shell in two
tests first.
llvm-svn: 242312
MSVC 4.2 didn't have bool as a builtin type but MSVC 5.0 does. When
they added it, they added a macro (__BOOL_DEFINED) which allows build
scripts and the like to know if they should provide their own bool.
Clang always supports bool as a builtin type in C++ mode.
llvm-svn: 242307
This fixes an off-by-one bug in CMICmdCmdDataInfoLine::Acknowledge. Given:
LineEntry: \[0x0000000100000f37-0x0000000100000f45\): /path/to/file:123:1
-data-info-line would report the line as 12, omitting the last digit.
Reviewed by: ki.stfu, abidh
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11209
llvm-svn: 242306
Summary:
This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with
the llgs main loop, we can get rid of the special monitor thread in NPL, which saves as a lot of
thread ping-pong when responding to client requests (e.g. qThreadInfo processing time has been
reduced by about 40%). It also makes the code simpler, IMHO.
Reviewers: ovyalov, clayborg, tberghammer, chaoren
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11150
llvm-svn: 242305
This is a necessary prerequisite for bootstrapping the emission
of debug info inside modules.
- Adds a FlagExternalTypeRef to DICompositeType.
External types must have a unique identifier.
- External type references are emitted using a forward declaration
with a DW_AT_signature([DW_FORM_ref_sig8]) based on the UID.
http://reviews.llvm.org/D9612
llvm-svn: 242302
I apologize for this nasty commit, but I somehow overlooked Chandler's
comment to re-indent these files to two space indention. I know this
is a horrible commit, but I figured if it was done quickly after the
first one, not too many conflicts would arise.
Again, I'm sorry and won't do this again.
llvm-svn: 242301
These were the cause of a verifier error when building 7zip with
-verify-machineinstrs. Running 'make check' with the verifier
triggered the same error on the test here so i've updated the test
to run the verifier on one of its runs instead of adding a new one.
While looking at this code, there was a stale comment that these
instructions were only used for disassembly. This probably used to
be the case, but they are now used in the 'ARM load / store optimization pass' too.
llvm-svn: 242300
This commit improves numerous functionalities of the OpenMP CMake build
system to be more conducive with LLVM's build system and build philosophies.
The CMake build system, as it was before this commit, was not up to LLVM's
standards and did not implement the configuration stage like most CMake based
build systems offer (check for compiler flags, libraries, etc.) In order to
improve it dramatically in a short period of time, a large refactoring had
to be done.
The main changes done with this commit are as follows:
* Compiler flag checks - The flags are no longer grabbed from compiler specific
directories. They are checked for availability in config-ix.cmake and added
accordingly inside LibompHandleFlags.cmake.
* Feature checks were added in config-ix.cmake. For example, the standard CMake
module FindThreads is probed for the threading model to use inside the OpenMP
library.
* OS detection - There is no longer a LIBOMP_OS variable, OS-specifc build logic
is wrapped around the WIN32 and APPLE macros with !(WIN32 OR APPLE) meaning
a Unix flavor of some sort.
* Got rid of vestigial functions/macros/variables
* Added new libomp_append() function which is used everywhere to conditionally
or undconditionally append to a list
* All targets have the libomp prefix so as not to interfere with any other
project
* LibompCheckLinkerFlag.cmake module was added which checks for linker flags
specifically for building shared libraries.
* LibompCheckFortranFlag.cmake module was added which checks for fortran flag
availability.
* Removed most of the cruft from the translation between the perl+Makefile based
build system and this one. The remaining components that they share are
perl scripts which I'm in the process of removing.
There is still more left to do. The perl scripts still need to be removed, and
a config.h.in file (or similarly named) needs to be added with #cmakedefine lines
in it. But this is a much better first step than the previous system.
Differential Revision: http://reviews.llvm.org/D10656
llvm-svn: 242298
The vec_sld interface provides access to the vsldoi instruction.
Unlike most of the vec_* interfaces, we do not attempt to change the
generated code for vec_sld based on the endian mode. It is too
difficult to correctly infer the desired semantics because of
different element types, and the corrected instruction sequence is
expensive, involving loading a permute control vector and performing a
generalized permute.
For GCC, this was implemented as "Don't touch the vec_sld"
implementation. When it came time for the LLVM implementation, I did
the same thing. However, this was hasty and incorrect. In LLVM's
version of altivec.h, vec_sld was previously defined in terms of the
vec_perm interface. Because vec_perm semantics are adjusted for
little endian, this means that leaving vec_sld untouched causes it to
generate something different for LE than for BE. Not good.
This patch adjusts the form of vec_perm that is used for vec_sld and
vec_vsldoi, effectively undoing the modifications so that the same
vsldoi instruction will be generated for both BE and LE.
There is an accompanying back-end patch to take care of some small
ripple effects caused by these changes.
llvm-svn: 242297
The vec_sld interface provides access to the vsldoi instruction.
Unlike most of the vec_* interfaces, we do not attempt to change the
generated code for vec_sld based on the endian mode. It is too
difficult to correctly infer the desired semantics because of
different element types, and the corrected instruction sequence is
expensive, involving loading a permute control vector and performing a
generalized permute.
For GCC, this was implemented as "Don't touch the vec_sld"
implementation. When it came time for the LLVM implementation, I did
the same thing. However, this was hasty and incorrect. In LLVM's
version of altivec.h, vec_sld was previously defined in terms of the
vec_perm interface. Because vec_perm semantics are adjusted for
little endian, this means that leaving vec_sld untouched causes it to
generate something different for LE than for BE. Not good.
This back-end patch accompanies the changes to altivec.h that change
vec_sld's behavior for little endian. Those changes mean that we see
slightly different code in the back end when trying to recognize a
VSLDOI instruction in isVSLDOIShuffleMask. In particular, a
ShuffleKind of 1 (where the two inputs are identical) must now be
treated the same way as a ShuffleKind of 2 (little endian with
different inputs) when little endian mode is in force. This is
because ShuffleKind of 1 is defined using big-endian numbering.
This has a ripple effect on LowerBUILD_VECTOR, where we create our own
internal VSLDOI instructions. Because these are a ShuffleKind of 1,
they will now have their shift amounts subtracted from 16 when
recognizing the shuffle mask. To avoid problems we have to subtract
them from 16 again before creating the VSLDOI instructions.
There are a couple of other uses of BuildVSLDOI, but these do not need
to be modified because the shift amount is 8, which is unchanged when
subtracted from 16.
llvm-svn: 242296
- Teaches the ValueTracker in the PeepholeOptimizer to look through PHI
instructions.
- Add findNextSourceAndRewritePHI method to lookup into multiple sources
returnted by the ValueTracker and rewrite PHIs with new sources.
With these changes we can find more register sources and rewrite more
copies to allow coaslescing of bitcast instructions. Hence, we eliminate
unnecessary VR64 <-> GR64 copies in x86, but it could be extended to
other archs by marking "isBitcast" on target specific instructions. The
x86 example follows:
A:
psllq %mm1, %mm0
movd %mm0, %r9
jmp C
B:
por %mm1, %mm0
movd %mm0, %r9
jmp C
C:
movd %r9, %mm0
pshufw $238, %mm0, %mm0
Becomes:
A:
psllq %mm1, %mm0
jmp C
B:
por %mm1, %mm0
jmp C
C:
pshufw $238, %mm0, %mm0
Differential Revision: http://reviews.llvm.org/D11197
rdar://problem/20404526
llvm-svn: 242295
- Create a new CopyRewriter for Uncoalescable copy-like instructions
- Change the ValueTracker to return a ValueTrackerResult
This makes optimizeUncoalescable looks more like optimizeCoalescable and
use the CopyRewritter infrastructure.
This is also the preparation for looking up into PHI nodes in the
ValueTracker.
Differential Revision: http://reviews.llvm.org/D11195
llvm-svn: 242294
Summary:
libtool_VERSION was changed in gofrontend a while ago,
but CMakeLists.txt in llgo wasn't updated, and so the
install target fails. Not sure how this went unnoticed
for so long.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11118
llvm-svn: 242291
Summary:
If a function requires a landing pad, set the personality function.
Requires D11116.
Reviewers: pcc
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11117
llvm-svn: 242290
Summary:
Add Value.SetPersonality to the Go bindings. The Go
bindings' Builder.CreateLandingPad has been updated,
removing the obsolete personality argument.
Background
The personality attribute was removed from LandingPadInst
in r239940, and llvm::Function::setPersonalityFn introduced.
There was no corresponding change to either the C API or
Go bindings. The Go bindings were broken until r239940, but
that change was just to ignore the personality argument.
This broke llgo.
Reviewers: majnemer, pcc
Subscribers: deadalnix, llvm-commits, axw
Differential Revision: http://reviews.llvm.org/D11116
llvm-svn: 242289
We now use the sanitizer special case list to decide which types to blacklist.
We also support a special blacklist entry for types with a uuid attribute,
which are generally COM types whose virtual tables are defined externally.
Differential Revision: http://reviews.llvm.org/D11096
llvm-svn: 242286
inspection.
While we want to handle calls specially in this code because they should
have been modeled by the call graph analysis that precedes it, we should
*not* be re-implementing the predicates for whether an instruction reads
or writes memory. Those are well defined already. Notably, at least the
following issues seem to be clearly missed before:
- Ordered atomic loads can "write" to memory by causing writes from other
threads to become visible. Similarly for ordered atomic stores.
- AtomicRMW instructions quite obviously both read and write to memory.
- AtomicCmpXchg instructions also read and write to memory.
- Fences read and write to memory.
- Invokes of intrinsics or memory allocation functions.
I don't have any test cases, and I suspect this has never really come up
in the real world. But there is no reason why it wouldn't, and it makes
the code simpler to do this the right way.
While here, I've tried to make the loops significantly simpler as well
and added helpful comments as to what is going on.
llvm-svn: 242281
Current implementation handles unordered comparison poorly in soft-float mode.
Consider (a ULE b) which is a <= b. It is lowered to (ledf2(a, b) <= 0 || unorddf2(a, b) != 0) (in general). We can do better job by lowering it to (__gtdf2(a, b) <= 0).
Such replacement is true for other CMP's (ult, ugt, uge). In general, we just call same function as for ordered case but negate comparison against zero.
Differential Revision: http://reviews.llvm.org/D10804
llvm-svn: 242280
Rafael Espindola