callers had to do this by hand and we ended up never actually adding initial arguments and then
reusing them by passing in the struct address separately, so the distinction wasn't needed.
llvm-svn: 252108
1. A macro with argument: LLVM_PACKED(StructDefinition)
2. A pair of macros defining scope of region with packing:
LLVM_PACKED_START
struct A { ... };
struct B { ... };
LLVM_PACKED_END
Differential Revision: http://reviews.llvm.org/D14337
llvm-svn: 252099
Summary:
Earlier CaptureTracking would assume all "interesting" operands to a
call or invoke were its arguments. With operand bundles this is no
longer true.
Note: an earlier change got `doesNotCapture` working correctly with
operand bundles.
This change uses DSE to test the changes to CaptureTracking. DSE is a
vehicle for testing only, and is not directly involved in this change.
Reviewers: reames, majnemer
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14306
llvm-svn: 252095
Summary:
This change makes the CMake build system generate libraries for Linux and Darwin matching the makefile build system.
Linux libraries follow the pattern lib${name}.${MAJOR}.${MINOR}.so so that ldconfig won't pick it up incorrectly.
Darwin libraries are not versioned.
Note: On linux the non-versioned symlink is generated at install-time not build time. I plan to fix that eventually, but I expect that is good enough for the purposes of fixing this bug.
Reviewers: loladiro, tstellarAMD
Subscribers: axw, llvm-commits
Differential Revision: http://reviews.llvm.org/D13841
llvm-svn: 252093
Python 3 introduces the `timeout` keyword argument on Popen.wait().
If our patched version doesn't support keyword arguments, then when
the internal Python implementation attempts to call wait() with the
keyword argument, things will explode.
Such as my head, after I finally figured out what was happening.
llvm-svn: 252092
The generic infrastructure already did a lot of work to decide if the
fixup value is know or not. It doesn't make sense to reimplement a very
basic case: same fragment.
llvm-svn: 252090
Win64 has some strict requirements for the epilogue. As a result, we disable
shrink-wrapping for Win64 unless the block that gets the epilogue is already an
exit block.
Fixes PR24193.
llvm-svn: 252088
Splits PrintLoopPass into a new-style pass and a PrintLoopPassWrapper,
much like we already do for PrintFunctionPass and PrintModulePass.
llvm-svn: 252085
This is part-1 of the patch that replaces all edge weights in MBB by
probabilities, which only adds new interfaces. No functional changes.
Differential revision: http://reviews.llvm.org/D13908
llvm-svn: 252083
This is a refactoring of the task_team code that more elegantly handles the two
task_team case. Two task_teams per team are kept in use for the lifetime of the
team. Thus no reference counting is needed.
Differential Revision: http://reviews.llvm.org/D13993
llvm-svn: 252082
This commit creates a new 'optin' top-level checker package and moves several of
the localizability checkers into it.
This package is for checkers that are not alpha and that would normally be on by
default but where the driver does not have enough information to determine when
they are applicable. The localizability checkers fit this criterion because the
driver cannot determine whether a project is localized or not -- this is best
determined at the IDE or build-system level.
This new package is *not* intended for checkers that are too noisy to be on by
default.
The hierarchy under 'optin' mirrors that in 'alpha': checkers under 'optin'
should be organized in the hierarchy they would have had if they were truly top
level (e.g., optin.osx.cocoa.MyOptInChecker).
Differential Revision: http://reviews.llvm.org/D14303
llvm-svn: 252080
Summary:
Data operands of a call or invoke consist of the call arguments, and
the bundle operands associated with the `call` (or `invoke`)
instruction. The motivation for this change is that we'd like to be
able to query "argument attributes" like `readonly` and `nocapture`
for bundle operands naturally.
This change also provides a conservative "implementation" for these
attributes for any bundle operand, and an extension point for future
work.
Reviewers: chandlerc, majnemer, reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14305
llvm-svn: 252077
Summary:
This prints NO if LLVM was built with -fno-rtti or an equivalent flag
and YES otherwise. The reasons to add -has-rtti rather than adding -fno-rtti
to --cxxflags are:
1. Building LLVM with -fno-rtti does not always mean that client
applications need this flag.
2. Some compilers have a different flag for disabling rtti, and the
compiler being used to build LLVM may not be the compiler being used to
build the application.
Reviewers: echristo, chandlerc, beanz
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D11849
llvm-svn: 252075
This patch improves the memory folding of the inserted float element for the (V)INSERTPS instruction.
The existing implementation occurs in the DAGCombiner and relies on the narrowing of a whole vector load into a scalar load (and then converted into a vector) to (hopefully) allow folding to occur later on. Not only has this proven problematic for debug builds, it also prevents other memory folds (notably stack reloads) from happening.
This patch removes the old implementation and moves the folding code to the X86 foldMemoryOperand handler. A new private 'special case' function - foldMemoryOperandCustom - has been added to deal with memory folding of instructions that can't just use the lookup tables - (V)INSERTPS is the first of several that could be done.
It also tweaks the memory operand folding code with an additional pointer offset that allows existing memory addresses to be modified, in this case to convert the vector address to the explicit address of the scalar element that will be inserted.
Unlike the previous implementation we now set the insertion source index to zero, although this is ignored for the (V)INSERTPSrm version, anything that relied on shuffle decodes (such as unfolding of insertps loads) was incorrectly calculating the source address - I've added a test for this at insertps-unfold-load-bug.ll
Differential Revision: http://reviews.llvm.org/D13988
llvm-svn: 252074
Summary:
This is intended to make a later change simpler.
Note: adding this bounds checking required fixing `X86FastISel`. As
far I can tell I've preserved original behavior but a careful review
will be appreciated.
Reviewers: reames
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14304
llvm-svn: 252073
internal linkage entities in different modules from r250884 to apply to all
names, not just function names.
This is really awkward: we don't want to merge internal-linkage symbols from
separate modules, because they might not actually be defining the same entity.
But we don't want to reject programs that use such an ambiguous symbol if those
internal-linkage symbols are in fact equivalent. For now, we're resolving the
ambiguity by picking one of the equivalent definitions as an extension.
llvm-svn: 252063
Summary: Diagnose when the 'concept' specifier is used on a typedef or function parameter.
Reviewers: rsmith, hubert.reinterpretcast, aaron.ballman, faisalv
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14316
llvm-svn: 252061
Patch by Slava Klochkov
The key difference between FMA* and FMA*_Int opcodes is that FMA*_Int opcodes are handled more conservatively. It is illegal to commute the 1st operand of FMA*_Int instructions as the upper bits of scalar FMA intrinsic result must be taken from the 1st operand, but such commute transformation would change those upper bits and invalidate the intrinsic's result.
Reviewers: Quentin Colombet, Elena Demikhovsky
Differential Revision: http://reviews.llvm.org/D13710
llvm-svn: 252060
LLDB recently started supporting LLDB.framework without a
debugserver in it. When that happens, the Xcode-included debugserver
is searched for and used. This change fixes the code that looks for
Xcode when the housing process is not Xcode. In particular, this
addresses the problem where python is running the test suite and
the LLDB.framework does not contain a debugserver.
llvm-svn: 252059
Ryan Brown