| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 208506
|
| |
|
|
|
|
|
|
| |
Filed as PR19712, LLVM fails to detect the right type of an enum
constant when a frontend does not provide an underlying type for the
enumeration type.
llvm-svn: 208502
|
| |
|
|
|
|
|
|
|
|
|
| |
The counter-loops formation pass needs to know what operations might be
function calls (because they can't appear in counter-based loops). On PPC32,
128-bit shifts might be runtime calls (even though you can't use __int128 on
PPC32, it seems that SROA might form them).
Fixes PR19709.
llvm-svn: 208501
|
| |
|
|
|
|
|
|
|
| |
And the winner by a nose is isUnsignedDIType, for no particular reason.
These two functions were just complements of each other and used in very
related code, so refactor callers to just use one of them.
llvm-svn: 208500
|
| |
|
|
|
|
| |
each caller of emitConstantValue doesn't have to call it separately.
llvm-svn: 208496
|
| |
|
|
|
|
|
|
|
|
|
|
| |
64 bit) and MCOperand immediates.
Doesn't seem a good reason to duplicate this code (it was more literally
duplicated prior to r208494, and while the dataN code /does/ actually
fire in this case, it doesn't seem necessary (and the DWARF standard
recommends using udata/sdata pervasively instead of dataN, so as to
indicate signedness of the values))
llvm-svn: 208495
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This code looks to have become dead at some time in the past. I tried to
reproduce cases where LLVM would emit constants with dataN, but could
not. Upon inspection it seems the code doesn't do that anymore - the
only time a size is provided by isTypeSigned is when the type is signed,
and in those cases we use sdata. dataN is only used for unsigned types
and isTypeSigned doesn't provide a value for sizeInBits in that case.
Remove the dead cases/size plumbing.
llvm-svn: 208494
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
completely.
Turns out that there is a very cheap way of testing whether a block is dead,
just look it up in the DomTree. We have to do this anyways so just ignore
unreachable blocks before sorting by domination. This restores a proper
ordering for std::stable_sort when dead code is present.
Covered by existing tests & buildbots running in STL debug mode (MSVC).
llvm-svn: 208492
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch enables transformations:
BinOp(shuffle(v1), shuffle(v2)) -> shuffle(BinOp(v1, v2))
BinOp(shuffle(v1), const1) -> shuffle(BinOp, const2)
They allow to eliminate extra shuffles in some cases.
Differential Revision: http://reviews.llvm.org/D3525
llvm-svn: 208488
|
| |
|
|
|
|
|
|
| |
When lowering build_vector to an insertps, we would still lower it, even
if the source vectors weren't v4x32. This would break on avx if the source
was a v8x32. We now check the type of the source vectors.
llvm-svn: 208487
|
| |
|
|
| |
llvm-svn: 208480
|
| |
|
|
| |
llvm-svn: 208479
|
| |
|
|
| |
llvm-svn: 208478
|
| |
|
|
| |
llvm-svn: 208476
|
| |
|
|
|
|
|
|
|
|
| |
We were swapping the true & false results while testing for FMAX/FMIN,
but not putting them back to the original state if the later checks
failed.
Should fix PR19700.
llvm-svn: 208469
|
| |
|
|
|
|
|
|
|
|
|
|
| |
unreachable code.
There is no total ordering if the CFG is disconnected. We don't care if we
catch all CSE opportunities in dead code either so just exclude ignore them in
the assert.
PR19646
llvm-svn: 208461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r200561.
This calling convention was an attempt to match the MSVC C++ ABI for
methods that return structures by value. This solution didn't scale,
because it would have required splitting every CC available on Windows
into two: one for methods and one for free functions.
Now that we can put sret on the second arg (r208453), and Clang does
that (r208458), revert this hack.
llvm-svn: 208459
|
| |
|
|
|
|
|
| |
we do not use the information from SCEVAddRecExpr to compute the shape of the array,
so a better place for this function is in ScalarEvolution.
llvm-svn: 208456
|
| |
|
|
| |
llvm-svn: 208455
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
MSVC always places the implicit sret parameter after the implicit this
parameter of instance methods. We used to handle this for
x86_thiscallcc by allocating the sret parameter on the stack and leaving
the this pointer in ecx, but that doesn't handle alternative calling
conventions like cdecl, stdcall, fastcall, or the win64 convention.
Instead, change the verifier to allow sret on the second parameter.
This also requires changing the Mips and X86 backends to return the
argument with the sret parameter, instead of assuming that the sret
parameter comes first.
The Sparc backend also returns sret parameters in a register, but I
wasn't able to update it to handle secondary sret parameters. It
currently calls report_fatal_error if you feed it an sret in the second
parameter.
Reviewers: rafael.espindola, majnemer
Differential Revision: http://reviews.llvm.org/D3617
llvm-svn: 208453
|
| |
|
|
|
|
|
|
| |
One error we were not deleting the alias or putting it in the Module. The
end result is that there was an use left of the aliasee when the module was
deleted.
llvm-svn: 208447
|
| |
|
|
|
|
| |
ARM64 backend was missing a required_library entry.
llvm-svn: 208437
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support to ARM for custom lowering of the
llvm.{u|s}add.with.overflow.i32 intrinsics for i32/i64. This is particularly useful
for handling idiomatic saturating math functions as generated by
InstCombineCompare.
Test cases included.
rdar://14853450
llvm-svn: 208435
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since ExtractValue is not included in ComputeSpeculationCost CFGs containing
ExtractValueInsts cannot be simplified. In particular this interacts with
InstCombineCompare's tendency to insert add.with.overflow intrinsics for
certain idiomatic math operations, preventing optimization.
This patch adds ExtractValue to the ComputeSpeculationCost. Test case included
rdar://14853450
llvm-svn: 208434
|
| |
|
|
| |
llvm-svn: 208432
|
| |
|
|
|
|
| |
We were dropping the high bits of 64-bit immediate offsets.
llvm-svn: 208431
|
| |
|
|
| |
llvm-svn: 208430
|
| |
|
|
| |
llvm-svn: 208429
|
| |
|
|
| |
llvm-svn: 208421
|
| |
|
|
| |
llvm-svn: 208419
|
| |
|
|
| |
llvm-svn: 208416
|
| |
|
|
| |
llvm-svn: 208415
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-mcpu=mips[123] does not accept them
Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-IV that was available in MIPS32
A small number of instructions are correctly rejected but with the wrong error
message. These have been placed in a separate test for now.
Depends on D3676
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3677
llvm-svn: 208414
|
| |
|
|
|
|
|
|
|
|
| |
When using the ARM AAPCS, HFAs (Homogeneous Floating-point Aggregates) must
be passed in a block of consecutive floating-point registers, or on the stack.
This means that unused floating-point registers cannot be back-filled with
part of an HFA, however this can currently happen. This patch, along with the
corresponding clang patch (http://reviews.llvm.org/D3083) prevents this.
llvm-svn: 208413
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
No functional change
Depends on D3675
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3676
llvm-svn: 208410
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-mcpu=mips[12] does not accept them
Summary:
This required a new instruction group representing the 32-bit subset of
MIPS-III that was available in MIPS32
A small number of instructions are correctly rejected but with the wrong error
message. These have been placed in a separate test for now.
There's some obvious InstAlias's that ought to be marked MIPS-III but arent.
This is because they are not currently tested. I intend to catch these with
a final pass through the tablegen records to find tablegen records without
ISA annotations.
Depends on D3674
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3675
llvm-svn: 208408
|
| |
|
|
|
|
| |
No functional change intended.
llvm-svn: 208405
|
| |
|
|
| |
llvm-svn: 208400
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Adds MIPS32r6/MIPS64r6 and checks the compatibility requirements for these
processors.
I've also included comments to describe removed and re-encoded instructions,
along with placeholder def's for the new instructions but there are no
functional changes to codegen at this point.
Reviewers: jkolek, vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3622
llvm-svn: 208399
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Summary: dsll, dsrl, sll, and srl already exist.
Reviewers: vmedic
Reviewed By: vmedic
Differential Revision: http://reviews.llvm.org/D3673
llvm-svn: 208397
|
| |
|
|
|
|
|
| |
Fix error handling introduced in r127426 that could result in MemoryBuffers not
having null termination.
llvm-svn: 208396
|
| |
|
|
|
|
| |
These were made redundant back in r186560.
llvm-svn: 208395
|
| |
|
|
|
|
|
|
| |
Handle lowering of global addresses for PIC mode compilation on Windows. Always
use the movw/movt load to load the address as Windows on ARM requires ARMv7+ and
is a pure Thumb environment.
llvm-svn: 208385
|
| |
|
|
| |
llvm-svn: 208383
|
| |
|
|
|
|
|
|
|
| |
around RelocationEntries, rather than passing the same information via loose
arguments.
No functional change.
llvm-svn: 208375
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Also ran clang-format on the function. The code added is the last else
if block.
Reviewers: nadav, craig.topper, delena
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D3518
llvm-svn: 208372
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
comment of the API.
Relaxes the behavior of TargetInstrInfo::commuteInstruction when
TargetInstrInfo::findCommutedOpIndices returns false.
Previously TargetInstrInfo triggered a fatal error in such situation whereas based
on the comment in the API it should just return nullptr. Indeed the only
precondition that should be ensured is that the instruction must be commutable.
llvm-svn: 208371
|
| |
|
|
| |
llvm-svn: 208370
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
workaround for an MSVC2012 bug regarding forward_as_tuple
(r207876 was reverted in r208131 after seeing some consistent buildbot
failure for MSVC 2012. The original commits were in r207724-r207726)
Takumi was nice enough to dig into this and locate this Microsoft
Connect issue:
http://connect.microsoft.com/VisualStudio/feedback/details/814899/forward-as-tuple-debug-implementation-error
describing a bug in MSVC2012's forward_as_tuple implementation.
Since the parameters in this instance are trivial/small, pass them by
value (using make_tuple) instead of perfectly-forwarded tuple of rvalue
references (involving the broken forward_as_tuple). Hopefully this will
satisfy MSVC2012.
llvm-svn: 208364
|
| |
|
|
|
|
|
|
| |
Sorry for the commit spam. My clang-format crashed on me and the vim
plugin did not print an error, but instead just left the formatting
untouched.
llvm-svn: 208358
|