#
d83f818a |
| 04-Jul-2016 |
Craig Topper <craig.topper@gmail.com> |
[CodeGen] Make the code that detects a if a shuffle is really a concatenation of the inputs more general purpose.
We can now handle concatenation of each source multiple times. The previous code jus
[CodeGen] Make the code that detects a if a shuffle is really a concatenation of the inputs more general purpose.
We can now handle concatenation of each source multiple times. The previous code just checked for each source to appear once in either order.
This also now handles an entire source vector sized piece having undef indices correctly. We now concat with UNDEF instead of using one of the sources. This is responsible for the test case change.
llvm-svn: 274483
show more ...
|
#
2bd8b4b1 |
| 01-Jul-2016 |
Craig Topper <craig.topper@gmail.com> |
[CodeGen,Target] Remove the version of DAG.getVectorShuffle that takes a pointer to a mask array. Convert all callers to use the ArrayRef version. No functional change intended.
For the most part th
[CodeGen,Target] Remove the version of DAG.getVectorShuffle that takes a pointer to a mask array. Convert all callers to use the ArrayRef version. No functional change intended.
For the most part this simplifies all callers. There were two places in X86 that needed an explicit makeArrayRef to shorten a statically sized array.
llvm-svn: 274337
show more ...
|
#
db6bd021 |
| 30-Jun-2016 |
Rafael Espindola <rafael.espindola@gmail.com> |
Delete unused includes. NFC.
llvm-svn: 274225
|
#
0526e7f8 |
| 22-Jun-2016 |
Wei Ding <wei.ding2@amd.com> |
AMDGPU: Add convergent flag to INLINEASM instruction.
Differential Revision: http://reviews.llvm.org/D21214
llvm-svn: 273455
|
#
e116d500 |
| 22-Jun-2016 |
Krzysztof Parzyszek <kparzysz@codeaurora.org> |
[SDAG] Remove FixedArgs parameter from CallLoweringInfo::setCallee
The setCallee function will set the number of fixed arguments based on the size of the argument list. The FixedArgs parameter was o
[SDAG] Remove FixedArgs parameter from CallLoweringInfo::setCallee
The setCallee function will set the number of fixed arguments based on the size of the argument list. The FixedArgs parameter was often explicitly set to 0, leading to a lack of consistent value for non- vararg functions.
Differential Revision: http://reviews.llvm.org/D20376
llvm-svn: 273403
show more ...
|
#
fd4b6b9e |
| 17-Jun-2016 |
Marcin Koscielnicki <koriakin@0x04.net> |
[SelectionDAG] Don't treat library calls specially if marked with nobuiltin.
To be used by D19781.
Differential Revision: http://reviews.llvm.org/D19801
llvm-svn: 273039
|
#
bae1d89e |
| 14-Jun-2016 |
Diana Picus <diana.picus@linaro.org> |
[SelectionDAG] Remove exit-on-error flag from test (PR27765)
The exit-on-error flag in the ARM test is necessary in order to avoid an unreachable in the DAGTypeLegalizer, when trying to expand a phy
[SelectionDAG] Remove exit-on-error flag from test (PR27765)
The exit-on-error flag in the ARM test is necessary in order to avoid an unreachable in the DAGTypeLegalizer, when trying to expand a physical register. We can also avoid this situation by introducing a bitcast early on, where the invalid scalar-to-vector conversion is detected.
We also add a test for PowerPC, which goes through a similar code path in the SelectionDAGBuilder.
Fixes PR27765.
Differential Revision: http://reviews.llvm.org/D21061
llvm-svn: 272644
show more ...
|
#
bdc4956b |
| 12-Jun-2016 |
Benjamin Kramer <benny.kra@googlemail.com> |
Pass DebugLoc and SDLoc by const ref.
This used to be free, copying and moving DebugLocs became expensive after the metadata rewrite. Passing by reference eliminates a ton of track/untrack operation
Pass DebugLoc and SDLoc by const ref.
This used to be free, copying and moving DebugLocs became expensive after the metadata rewrite. Passing by reference eliminates a ton of track/untrack operations. No functionality change intended.
llvm-svn: 272512
show more ...
|
#
22bfa832 |
| 07-Jun-2016 |
Etienne Bergeron <etienneb@google.com> |
[stack-protection] Add support for MSVC buffer security check
Summary: This patch is adding support for the MSVC buffer security check implementation
The buffer security check is turned on with the
[stack-protection] Add support for MSVC buffer security check
Summary: This patch is adding support for the MSVC buffer security check implementation
The buffer security check is turned on with the '/GS' compiler switch. * https://msdn.microsoft.com/en-us/library/8dbf701c.aspx * To be added to clang here: http://reviews.llvm.org/D20347
Some overview of buffer security check feature and implementation: * https://msdn.microsoft.com/en-us/library/aa290051(VS.71).aspx * http://www.ksyash.com/2011/01/buffer-overflow-protection-3/ * http://blog.osom.info/2012/02/understanding-vs-c-compilers-buffer.html
For the following example: ``` int example(int offset, int index) { char buffer[10]; memset(buffer, 0xCC, index); return buffer[index]; } ```
The MSVC compiler is adding these instructions to perform stack integrity check: ``` push ebp mov ebp,esp sub esp,50h [1] mov eax,dword ptr [__security_cookie (01068024h)] [2] xor eax,ebp [3] mov dword ptr [ebp-4],eax push ebx push esi push edi mov eax,dword ptr [index] push eax push 0CCh lea ecx,[buffer] push ecx call _memset (010610B9h) add esp,0Ch mov eax,dword ptr [index] movsx eax,byte ptr buffer[eax] pop edi pop esi pop ebx [4] mov ecx,dword ptr [ebp-4] [5] xor ecx,ebp [6] call @__security_check_cookie@4 (01061276h) mov esp,ebp pop ebp ret ```
The instrumentation above is: * [1] is loading the global security canary, * [3] is storing the local computed ([2]) canary to the guard slot, * [4] is loading the guard slot and ([5]) re-compute the global canary, * [6] is validating the resulting canary with the '__security_check_cookie' and performs error handling.
Overview of the current stack-protection implementation: * lib/CodeGen/StackProtector.cpp * There is a default stack-protection implementation applied on intermediate representation. * The target can overload 'getIRStackGuard' method if it has a standard location for the stack protector cookie. * An intrinsic 'Intrinsic::stackprotector' is added to the prologue. It will be expanded by the instruction selection pass (DAG or Fast). * Basic Blocks are added to every instrumented function to receive the code for handling stack guard validation and errors handling. * Guard manipulation and comparison are added directly to the intermediate representation.
* lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp * lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp * There is an implementation that adds instrumentation during instruction selection (for better handling of sibbling calls). * see long comment above 'class StackProtectorDescriptor' declaration. * The target needs to override 'getSDagStackGuard' to activate SDAG stack protection generation. (note: getIRStackGuard MUST be nullptr). * 'getSDagStackGuard' returns the appropriate stack guard (security cookie) * The code is generated by 'SelectionDAGBuilder.cpp' and 'SelectionDAGISel.cpp'.
* include/llvm/Target/TargetLowering.h * Contains function to retrieve the default Guard 'Value'; should be overriden by each target to select which implementation is used and provide Guard 'Value'.
* lib/Target/X86/X86ISelLowering.cpp * Contains the x86 specialisation; Guard 'Value' used by the SelectionDAG algorithm.
Function-based Instrumentation: * The MSVC doesn't inline the stack guard comparison in every function. Instead, a call to '__security_check_cookie' is added to the epilogue before every return instructions. * To support function-based instrumentation, this patch is * adding a function to get the function-based check (llvm 'Value', see include/llvm/Target/TargetLowering.h), * If provided, the stack protection instrumentation won't be inlined and a call to that function will be added to the prologue. * modifying (SelectionDAGISel.cpp) do avoid producing basic blocks used for inline instrumentation, * generating the function-based instrumentation during the ISEL pass (SelectionDAGBuilder.cpp), * if FastISEL (not SelectionDAG), using the fallback which rely on the same function-based implemented over intermediate representation (StackProtector.cpp).
Modifications * adding support for MSVC (lib/Target/X86/X86ISelLowering.cpp) * adding support function-based instrumentation (lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp, .h)
Results
* IR generated instrumentation: ``` clang-cl /GS test.cc /Od /c -mllvm -print-isel-input ```
``` *** Final LLVM Code input to ISel ***
; Function Attrs: nounwind sspstrong define i32 @"\01?example@@YAHHH@Z"(i32 %offset, i32 %index) #0 { entry: %StackGuardSlot = alloca i8* <<<-- Allocated guard slot %0 = call i8* @llvm.stackguard() <<<-- Loading Stack Guard value call void @llvm.stackprotector(i8* %0, i8** %StackGuardSlot) <<<-- Prologue intrinsic call (store to Guard slot) %index.addr = alloca i32, align 4 %offset.addr = alloca i32, align 4 %buffer = alloca [10 x i8], align 1 store i32 %index, i32* %index.addr, align 4 store i32 %offset, i32* %offset.addr, align 4 %arraydecay = getelementptr inbounds [10 x i8], [10 x i8]* %buffer, i32 0, i32 0 %1 = load i32, i32* %index.addr, align 4 call void @llvm.memset.p0i8.i32(i8* %arraydecay, i8 -52, i32 %1, i32 1, i1 false) %2 = load i32, i32* %index.addr, align 4 %arrayidx = getelementptr inbounds [10 x i8], [10 x i8]* %buffer, i32 0, i32 %2 %3 = load i8, i8* %arrayidx, align 1 %conv = sext i8 %3 to i32 %4 = load volatile i8*, i8** %StackGuardSlot <<<-- Loading Guard slot call void @__security_check_cookie(i8* %4) <<<-- Epilogue function-based check ret i32 %conv } ```
* SelectionDAG generated instrumentation:
``` clang-cl /GS test.cc /O1 /c /FA ```
``` "?example@@YAHHH@Z": # @"\01?example@@YAHHH@Z" # BB#0: # %entry pushl %esi subl $16, %esp movl ___security_cookie, %eax <<<-- Loading Stack Guard value movl 28(%esp), %esi movl %eax, 12(%esp) <<<-- Store to Guard slot leal 2(%esp), %eax pushl %esi pushl $204 pushl %eax calll _memset addl $12, %esp movsbl 2(%esp,%esi), %esi movl 12(%esp), %ecx <<<-- Loading Guard slot calll @__security_check_cookie@4 <<<-- Epilogue function-based check movl %esi, %eax addl $16, %esp popl %esi retl ```
Reviewers: kcc, pcc, eugenis, rnk
Subscribers: majnemer, llvm-commits, hans, thakis, rnk
Differential Revision: http://reviews.llvm.org/D20346
llvm-svn: 272053
show more ...
|
#
c04a76c1 |
| 26-May-2016 |
Justin Bogner <mail@justinbogner.com> |
SDAG: Use an Optional<> instead of a sigil value. NFC
This just makes it a bit more clear that we don't intend to use a deleted node for anything here.
llvm-svn: 270931
|
#
86f1f4ca |
| 20-May-2016 |
Diana Picus <diana.picus@linaro.org> |
Fix some comment typos in SelectionDAGBuilder. NFC
llvm-svn: 270190
|
#
38ed8021 |
| 17-May-2016 |
Renato Golin <renato.golin@linaro.org> |
Fix an assert in SelectionDAGBuilder when processing inline asm
When processing inline asm that contains errors, make sure we can recover gracefully by creating an UNDEF SDValue for the inline asm s
Fix an assert in SelectionDAGBuilder when processing inline asm
When processing inline asm that contains errors, make sure we can recover gracefully by creating an UNDEF SDValue for the inline asm statement before returning from SelectionDAGBuilder::visitInlineAsm. This is necessary for consumers that don't exit on the first error that is emitted (e.g. clang) and that would assert later on.
Fixes PR24071.
Patch by Diana Picus.
llvm-svn: 269811
show more ...
|
#
c31a9d06 |
| 16-May-2016 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
SelectionDAG: Select min/max when both are used
Allow two users of the condition if the other user is also a min/max select. i.e.
%c = icmp slt i32 %x, %y %min = select i1 %c, i32 %x, i32 %y %max =
SelectionDAG: Select min/max when both are used
Allow two users of the condition if the other user is also a min/max select. i.e.
%c = icmp slt i32 %x, %y %min = select i1 %c, i32 %x, i32 %y %max = select i1 %c, i32 %y, i32 %x
llvm-svn: 269699
show more ...
|
#
110af565 |
| 01-May-2016 |
Igor Breger <igor.breger@intel.com> |
getelementptr instruction, support index vector of EVT.
Differential Revision: http://reviews.llvm.org/D19775
llvm-svn: 268195
|
#
a1d8bc55 |
| 19-Apr-2016 |
Tim Shen <timshen91@gmail.com> |
[PPC, SSP] Support PowerPC Linux stack protection.
llvm-svn: 266809
|
#
e885d5e4 |
| 19-Apr-2016 |
Tim Shen <timshen91@gmail.com> |
[SSP, 2/2] Create llvm.stackguard() intrinsic and lower it to LOAD_STACK_GUARD
With this change, ideally IR pass can always generate llvm.stackguard call to get the stack guard; but for now there ar
[SSP, 2/2] Create llvm.stackguard() intrinsic and lower it to LOAD_STACK_GUARD
With this change, ideally IR pass can always generate llvm.stackguard call to get the stack guard; but for now there are still IR form stack guard customizations around (see getIRStackGuard()). Future SSP customization should go through LOAD_STACK_GUARD.
There is a behavior change: stack guard values are not CSEed anymore, since we should never reuse the value in case that it has been spilled (and corrupted). See ssp-guard-spill.ll. This also cause the change of stack size and codegen in X86 and AArch64 test cases.
Ideally we'd like to know if the guard created in llvm.stackprotector() gets spilled or not. If the value is spilled, discard the value and reload stack guard; otherwise reuse the value. This can be done by teaching register allocator to know how to rematerialize LOAD_STACK_GUARD and force a rematerialization (which seems hard), or check for spilling in expandPostRAPseudo. It only makes sense when the stack guard is a global variable, which requires more instructions to load. Anyway, this seems to go out of the scope of the current patch.
llvm-svn: 266806
show more ...
|
#
0f26b0ae |
| 14-Apr-2016 |
David Majnemer <david.majnemer@gmail.com> |
[CodeGen] Teach LLVM how to lower @llvm.{min,max}num to {MIN,MAX}NAN
The behavior of {MIN,MAX}NAN differs from that of {MIN,MAX}NUM when only one of the inputs is NaN: -NUM will return the non-NaN a
[CodeGen] Teach LLVM how to lower @llvm.{min,max}num to {MIN,MAX}NAN
The behavior of {MIN,MAX}NAN differs from that of {MIN,MAX}NUM when only one of the inputs is NaN: -NUM will return the non-NaN argument while -NAN would return NaN.
It is desirable to lower to @llvm.{min,max}num to -NAN if they don't have a native instruction for -NUM. Notably, ARMv7 NEON's vmin has the -NAN semantics.
N.B. Of course, it is only safe to do this if the intrinsic call is marked nnan.
llvm-svn: 266279
show more ...
|
#
9cd90712 |
| 14-Apr-2016 |
Matt Arsenault <Matthew.Arsenault@amd.com> |
AMDGPU: Implement canonicalize
Also add generic DAG node for it.
llvm-svn: 266272
|
#
92d1f0cb |
| 12-Apr-2016 |
Philip Reames <listmail@philipreames.com> |
Introduce an GCRelocateInst class [NFC]
Previously, we were using isGCRelocate predicates. Using a subclass of IntrinsicInst is far more idiomatic. The refactoring also enables a couple of minor s
Introduce an GCRelocateInst class [NFC]
Previously, we were using isGCRelocate predicates. Using a subclass of IntrinsicInst is far more idiomatic. The refactoring also enables a couple of minor simplifications and code sharing.
llvm-svn: 266098
show more ...
|
#
00127564 |
| 08-Apr-2016 |
Tim Shen <timshen91@gmail.com> |
[SSP] Remove llvm.stackprotectorcheck.
This is a cleanup patch for SSP support in LLVM. There is no functional change. llvm.stackprotectorcheck is not needed, because SelectionDAG isn't actually low
[SSP] Remove llvm.stackprotectorcheck.
This is a cleanup patch for SSP support in LLVM. There is no functional change. llvm.stackprotectorcheck is not needed, because SelectionDAG isn't actually lowering it in SelectBasicBlock; rather, it adds check code in FinishBasicBlock, ignoring the position where the intrinsic is inserted (See FindSplitPointForStackProtector()).
llvm-svn: 265851
show more ...
|
#
800f87a8 |
| 06-Apr-2016 |
JF Bastien <jfb@google.com> |
NFC: make AtomicOrdering an enum class
Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 b
NFC: make AtomicOrdering an enum class
Summary: In the context of http://wg21.link/lwg2445 C++ uses the concept of 'stronger' ordering but doesn't define it properly. This should be fixed in C++17 barring a small question that's still open.
The code currently plays fast and loose with the AtomicOrdering enum. Using an enum class is one step towards tightening things. I later also want to tighten related enums, such as clang's AtomicOrderingKind (which should be shared with LLVM as a 'C++ ABI' enum).
This change touches a few lines of code which can be improved later, I'd like to keep it as NFC for now as it's already quite complex. I have related changes for clang.
As a follow-up I'll add: bool operator<(AtomicOrdering, AtomicOrdering) = delete; bool operator>(AtomicOrdering, AtomicOrdering) = delete; bool operator<=(AtomicOrdering, AtomicOrdering) = delete; bool operator>=(AtomicOrdering, AtomicOrdering) = delete; This is separate so that clang and LLVM changes don't need to be in sync.
Reviewers: jyknight, reames
Subscribers: jyknight, llvm-commits
Differential Revision: http://reviews.llvm.org/D18775
llvm-svn: 265602
show more ...
|
#
65a60670 |
| 06-Apr-2016 |
Sanjoy Das <sanjoy@playingwithpointers.com> |
Lower @llvm.experimental.deoptimize as a noreturn call
While preserving the return value for @llvm.experimental.deoptimize at the IR level is useful during mid-level optimization, doing so at the ma
Lower @llvm.experimental.deoptimize as a noreturn call
While preserving the return value for @llvm.experimental.deoptimize at the IR level is useful during mid-level optimization, doing so at the machine instruction level requires generating some extra code and a return that is non-ideal. This change has LLVM lower
``` %val = call @llvm.experimental.deoptimize ret %val ```
to effectively
``` call @__llvm_deoptimize() unreachable ```
instead.
llvm-svn: 265502
show more ...
|
#
e221a870 |
| 05-Apr-2016 |
Manman Ren <manman.ren@gmail.com> |
Swift Calling Convention: swifterror target-independent change.
At IR level, the swifterror argument is an input argument with type ErrorObject**. For targets that support swifterror, we want to opt
Swift Calling Convention: swifterror target-independent change.
At IR level, the swifterror argument is an input argument with type ErrorObject**. For targets that support swifterror, we want to optimize it to behave as an inout value with type ErrorObject*; it will be passed in a fixed physical register.
The main idea is to track the virtual registers for each swifterror value. We define swifterror values as AllocaInsts with swifterror attribute or a function argument with swifterror attribute.
In SelectionDAGISel.cpp, we set up swifterror values (SwiftErrorVals) before handling the basic blocks.
When iterating over all basic blocks in RPO, before actually visiting the basic block, we call mergeIncomingSwiftErrors to merge incoming swifterror values when there are multiple predecessors or to simply propagate them. There, we create a virtual register for each swifterror value in the entry block. For predecessors that are not yet visited, we create virtual registers to hold the swifterror values at the end of the predecessor. The assignments are saved in SwiftErrorWorklist and will be materialized at the end of visiting the basic block.
When visiting a load from a swifterror value, we copy from the current virtual register assignment. When visiting a store to a swifterror value, we create a virtual register to hold the swifterror value and update SwiftErrorMap to track the current virtual register assignment.
Differential Revision: http://reviews.llvm.org/D18108
llvm-svn: 265433
show more ...
|
#
9bfd0d03 |
| 01-Apr-2016 |
Manman Ren <manman.ren@gmail.com> |
Swift Calling Convention: add swifterror attribute.
A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst.
This commit does not include any target-specific change. The
Swift Calling Convention: add swifterror attribute.
A ``swifterror`` attribute can be applied to a function parameter or an AllocaInst.
This commit does not include any target-specific change. The target-specific optimization will come as a follow-up patch.
Differential Revision: http://reviews.llvm.org/D18092
llvm-svn: 265189
show more ...
|
#
9d41a8f2 |
| 01-Apr-2016 |
Sanjoy Das <sanjoy@playingwithpointers.com> |
Don't use an i64 return type with webkit_jscc
Re-enable an assertion enabled by Justin Lebar in rL265092. rL265092 was breaking test/CodeGen/X86/deopt-intrinsic.ll because webkit_jscc does not like
Don't use an i64 return type with webkit_jscc
Re-enable an assertion enabled by Justin Lebar in rL265092. rL265092 was breaking test/CodeGen/X86/deopt-intrinsic.ll because webkit_jscc does not like non-i64 return types. Change the test case to not do that.
llvm-svn: 265099
show more ...
|