| Commit message (Collapse) | Author | Age | Files | Lines | 
| ... |  | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This moves all of the PassManager <-> Target communication to use the
new pass manager's TargetIRAnalysis even with the old pass manager. See
the LLVM commit for some of why things are moving in this direction, but
the short version is that this will enable us to create per-function
TargetTransformInfo objects that have correct subtarget information for
that function.
llvm-svn: 227732
 | 
| | 
| 
| 
| 
| 
|  | 
TargetTransformInfo, and unify the code in a single place.
llvm-svn: 227686
 | 
| | 
| 
| 
| 
| 
|  | 
the GDB buildbot)
llvm-svn: 227663
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
Create a new TargetCodeGenInfo for Windows on ARM to permit annotating the
functions with stack-probe-size (for /Gs and -mstack-probe-support) for
generating the stack probe necessary for Windows targets.  This will be used by
the backend when lowering the frame to generate the stack probe appropriately.
llvm-svn: 227641
 | 
| | 
| 
| 
| 
| 
| 
|  | 
If both the __try and __except blocks do not return, we want to delete
the continuation block as unreachable instead.
llvm-svn: 227627
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
On targets which use the MSVCRT, setjmp is a macro which expands to
_setjmp or _setjmpex.
_setjmp and _setjmpex have a secret, hidden argument which is not listed
in the function prototype on X64 and WoA.  This hidden argument always
seems to be the frame pointer.
_setjmpex isn't used on X86, _setjmp is magically replaced with a call
to _setjmp3.  The second argument is zero for 'normal' setjmp/longjmp
pairs, otherwise it is a count of additional variadic arguments.  This
is used when setjmp appears inside of a try or __try.
It is not safe to use a pointer to setjmp because _setjmp, _setjmpex and
_setmp3 are not compatible with setjmp.
llvm-svn: 227426
 | 
| | 
| 
| 
| 
| 
| 
|  | 
Warnings shouldn't use getCustomDiagID(), since then they can't be disabled
via a flag, can't be remapped, etc.
llvm-svn: 227420
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
They just existed before to use NaCl's custom ABIInfos; now that those are gone,
the custom TargetCodeGenInfos are no longer needed either.
Test Plan: don't break the existing tests
Reviewers: jvoung
Subscribers: jfb, cfe-commits
Differential Revision: http://reviews.llvm.org/D7234
llvm-svn: 227406
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Summary:
It was used for interoperability with PNaCl's calling conventions, but
it's no longer needed.
Also Remove NaCl*ABIInfo which just existed to delegate to either the portable
or native ABIInfo, and remove checkCallingConvention which was now a no-op
override.
Reviewers: jvoung
Subscribers: jfb, llvm-commits
Differential Revision: http://reviews.llvm.org/D7206
llvm-svn: 227362
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
not to the outer use of that expression.
This is half a fix for a GDB test suite failure that expects to start at
'a' in the following code:
  void func(int a)
    if (a
        &&
	b)
	...
But instead, without this change, the comparison was assigned to '&&'
(well, worse actually - because there was a chained 'a && b && c' and it
was assigned to the second '&&' because of a recursive application of
this bug) and then the load folded into the comparison so breaking on
the function started at '&&' instead of 'a'.
The other part of this needs to be fixed in LLVM where it's ignoring the
location of the icmp and instead using the location of the branch
instruction.
The fix to the conditional operator is actually a no-op currently,
because the conditional operator's location coincides with 'a' (the
start of the conditional expression) but should probably be '?' instead.
See the FIXME in the test case that mentions the ARCMigration tool
failures when I tried to make that change.
llvm-svn: 227356
 | 
| | 
| 
| 
|  | 
llvm-svn: 227221
 | 
| | 
| 
| 
|  | 
llvm-svn: 227194
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The backend won't run LowerExpect on -O0.  In a debug LTO build, this results in llvm.expect intrinsics being in the LTO IR which doesn't know how to optimize them.
Thanks to Chandler for the suggestion and review.
Differential revision: http://reviews.llvm.org/D7183
llvm-svn: 227135
 | 
| | 
| 
| 
|  | 
llvm-svn: 227114
 | 
| | 
| 
| 
| 
| 
|  | 
the start of the whole expression
llvm-svn: 227028
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
expression line info
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
  commit). This meant that stepping through subexpressions would bounce
  around from subexpressions back to the start of the outer expression,
  etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
  where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
  certainly this for function calls. This has the advantage that
  progress is always 'forwards' (never jumping backwards - except for
  independent subexpressions if they're evaluated in interesting orders,
  etc). "x + y + z" would go "x y z" with the additions occurring at y
  and z after the respective loads.
  The problem with this is that the user would still have to think
  fairly hard about precedence to realize which subexpression is being
  evaluated or which operator overload is being called in, say, an asan
  backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
  you'd expect, though it's a bit confusing in its own way due to going
  'backwards'. In this case the locations would be: "x y + z +" in
  lovely postfix arithmetic order. But this does mean that if the op+
  were an operator overload, say, and in a backtrace, the backtrace will
  point to the exact '+' that's being called, not to the end of one of
  its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
 | 
| | 
| 
| 
|  | 
llvm-svn: 227023
 | 
| | 
| 
| 
|  | 
llvm-svn: 227015
 | 
| | 
| 
| 
|  | 
llvm-svn: 226982
 | 
| | 
| 
| 
|  | 
llvm-svn: 226968
 | 
| | 
| 
| 
| 
| 
|  | 
differentiate inline callsites.
llvm-svn: 226955
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
http://reviews.llvm.org/D7090
Patch by Gábor Horváth!
llvm-svn: 226914
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
In ItaniumCXXABI::EmitCXXDestructors we first emit the base destructor
and then try to emit the complete one as an alias.
If in the base ends up calling the complete destructor, the GD for the
complete will be in the list of deferred decl by the time we replace
it with an alias and delete the original GV.
llvm-svn: 226896
 | 
| | 
| 
| 
| 
| 
|  | 
Differential Revision: http://reviews.llvm.org/D7006
llvm-svn: 226795
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
"omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform
an atomic load of "x" (using builtin atomic loading instructions or a call to
"atomic_load()" for simple lvalues and "kmpc_atomic_start();load
<x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to
type of "v" (using EmitScalarConversion() for simple types and
EmitComplexToScalarConversion() for conversions from complex to scalar) and then
store the result in "v".)
Differential Revision: http://reviews.llvm.org/D6431
llvm-svn: 226788
 | 
| | 
| 
| 
| 
| 
|  | 
Need to add initialization of AtomicInfo::EvaluationKind field
llvm-svn: 226787
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
"omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform
an atomic load of "x" (using builtin atomic loading instructions or a call to
"atomic_load()" for simple lvalues and "kmpc_atomic_start();load
<x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to
type of "v" (using EmitScalarConversion() for simple types and
EmitComplexToScalarConversion() for conversions from complex to scalar) and then
store the result in "v".)
Differential Revision: http://reviews.llvm.org/D6431
llvm-svn: 226786
 | 
| | 
| 
| 
| 
| 
|  | 
Accidentally modified file SemaType.cpp must be restored to its original state. 
llvm-svn: 226785
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
"omp atomic read [seq_cst]" accepts expressions "v=x;". In this patch we perform
an atomic load of "x" (using builtin atomic loading instructions or a call to
"atomic_load()" for simple lvalues and "kmpc_atomic_start();load
<x>;kmpc_atomic_end();" for other lvalues), convert the result of loading to
type of "v" (using EmitScalarConversion() for simple types and
EmitComplexToScalarConversion() for conversions from complex to scalar) and then
store the result in "v".
Differential Revision: http://reviews.llvm.org/D6431
llvm-svn: 226784
 | 
| | 
| 
| 
| 
| 
|  | 
Minor optimization of code like __try { ... } __except(1) { ... }.
llvm-svn: 226766
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
We don't emit any coverage mapping for uncovered functions that come
from system headers, but we were creating a GlobalVariable with each
of their names. This is wasteful since the linker will need to dead
strip the unused symbols, and it can lead to issues when merging
coverage with others TUs that do have coverage for those functions.
llvm-svn: 226764
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The lowering looks a lot like normal EH lowering, with the exception
that the exceptions are caught by executing filter expression code
instead of matching typeinfo globals. The filter expressions are
outlined into functions which are used in landingpad clauses where
typeinfo would normally go.
Major aspects that still need work:
- Non-call exceptions in __try bodies won't work yet. The plan is to
  outline the __try block in the frontend to keep things simple.
- Filter expressions cannot use local variables until capturing is
  implemented.
- __finally blocks will not run after exceptions. Fixing this requires
  work in the LLVM SEH preparation pass.
The IR lowering looks like this:
// C code:
bool safe_div(int n, int d, int *r) {
  __try {
    *r = normal_div(n, d);
  } __except(_exception_code() == EXCEPTION_INT_DIVIDE_BY_ZERO) {
    return false;
  }
  return true;
}
; LLVM IR:
define i32 @filter(i8* %e, i8* %fp) {
  %ehptrs = bitcast i8* %e to i32**
  %ehrec = load i32** %ehptrs
  %code = load i32* %ehrec
  %matches = icmp eq i32 %code, i32 u0xC0000094
  %matches.i32 = zext i1 %matches to i32
  ret i32 %matches.i32
}
define i1 zeroext @safe_div(i32 %n, i32 %d, i32* %r) {
  %rr = invoke i32 @normal_div(i32 %n, i32 %d)
      to label %normal unwind to label %lpad
normal:
  store i32 %rr, i32* %r
  ret i1 1
lpad:
  %ehvals = landingpad {i8*, i32} personality i32 (...)* @__C_specific_handler
      catch i8* bitcast (i32 (i8*, i8*)* @filter to i8*)
  %ehptr = extractvalue {i8*, i32} %ehvals, i32 0
  %sel = extractvalue {i8*, i32} %ehvals, i32 1
  %filter_sel = call i32 @llvm.eh.seh.typeid.for(i8* bitcast (i32 (i8*, i8*)* @filter to i8*))
  %matches = icmp eq i32 %sel, %filter_sel
  br i1 %matches, label %eh.except, label %eh.resume
eh.except:
  ret i1 false
eh.resume:
  resume
}
Reviewers: rjmccall, rsmith, majnemer
Differential Revision: http://reviews.llvm.org/D5607
llvm-svn: 226760
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Currently we emit DeferredDeclsToEmit in reverse order. This patch changes that.
The advantages of the change are that
* The output order is a bit closer to the source order. The change to
test/CodeGenCXX/pod-member-memcpys.cpp is a good example.
* If we decide to deffer more, it will not cause as large changes in the
estcases as it would without this patch.
llvm-svn: 226751
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This workaround was to provide unique call sites to ensure LLVM's inline
debug info handling would properly unique two calls to the same function
on the same line. Instead, this has now been fixed in LLVM (r226736) and
the workaround here can be removed.
Originally committed in r176895, but this isn't a straight revert due to
all the changes since then. I just searched for anything ForcedColumn*
related and removed them.
We could test this - but it didn't strike me as terribly valuable once
we're no longer adding this workaround everything just works as expected
& it's no longer a special case to test for.
llvm-svn: 226738
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This attribute implies indicates that the function musttail calls
another function and returns whatever it returns. The return type of the
thunk is meaningless, as the thunk can dynamically call different
functions with different return types. So long as the callers bitcast
the thunk with the correct type, behavior is well defined.
This attribute was necessary to fix PR20944, where the indirect call
combiner noticed that the thunk returned void and replaced the results
of the indirect call instruction with undef.
Over-the-shoulder reviewed by David Majnemer.
llvm-svn: 226707
 | 
| | 
| 
| 
|  | 
llvm-svn: 226662
 | 
| | 
| 
| 
| 
| 
| 
|  | 
They can be emitted by multiple translation units and thus belong in a
COMDAT group.
llvm-svn: 226630
 | 
| | 
| 
| 
| 
| 
|  | 
A guard variable in a COMDAT'd function should also be in a COMDAT.
llvm-svn: 226629
 | 
| | 
| 
| 
|  | 
llvm-svn: 226628
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This code adds the -mstack-probe-size command line option and implements the /Gs
compiler switch for clang-cl.
This should fix http://llvm.org/bugs/show_bug.cgi?id=21896
Patch by Andrew H!
Differential Revision: http://reviews.llvm.org/D6685
llvm-svn: 226601
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The test was fixed after a discussion with the revision author: the check
pattern was made more flexible as the "%call" part is not what we actually want
to check strictly there.
The original patch description:
===
Introduce SPIR calling conventions.
This implements Section 3.7 from the SPIR 1.2 spec:
    SPIR kernels should use "spir_kernel" calling convention.
    Non-kernel functions use "spir_func" calling convention. All
    other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
===
llvm-svn: 226561
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
Here's the fail log from our internal setup:
===
  .../tools/clang/clang -cc1 -internal-isystem .../tools/clang/staging/include -nostdsysteminc .../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl -triple spir-unknown-unknown -emit-llvm -o -
  FileCheck .../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl
.../tools/clang/test/CodeGenOpenCL/spir-calling-conv.cl:11:12: error: expected string not found in input
 // CHECK: %call = tail call spir_func i32 @get_dummy_id(i32 0)
           ^
<stdin>:6:52: note: scanning from here
define spir_kernel void @foo(i32 addrspace(1)* %A) #0 {
                                                   ^
<stdin>:7:2: note: possible intended match here
 %1 = tail call spir_func i32 @get_dummy_id(i32 0) #2
 ^
===
Here's a failure on a public CI server:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/1183/
llvm-svn: 226558
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
This implements Section 3.7 from the SPIR 1.2 spec:
    SPIR kernels should use "spir_kernel" calling convention.
    Non-kernel functions use "spir_func" calling convention. All
    other calling conventions are disallowed.
The patch works only for OpenCL source. Any other uses will need
to ensure that kernels are assigned the spir_kernel calling
convention correctly.
llvm-svn: 226548
 | 
| | 
| 
| 
| 
| 
|  | 
`MDNode::getTemporary()` returns a `unique_ptr<>` as of r226504.
llvm-svn: 226505
 | 
| | 
| 
| 
| 
| 
|  | 
with a DW_OP_deref instead.
llvm-svn: 226474
 | 
| | 
| 
| 
|  | 
llvm-svn: 226465
 | 
| | 
| 
| 
| 
| 
|  | 
Code review suggestion by Eric Christopher.
llvm-svn: 226395
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
expression
Just as r225956 did for scalar expressions (CGExprScalar::Visit), do the
same for complex expressions.
llvm-svn: 226390
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
expression
Just as r225956 did for scalar expressions (CGExprScalar::Visit), do the
same for aggregate expressions.
llvm-svn: 226388
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
initializers from in class non-static data members are explicitly attributed to the desired line.
The code setting the debug location being removed here was accidentally
leaking a location into the call to the non-static data member's ctor
call. Without it the call had no location and could cause assertion
failures if it was inlined. Now that it has a location (and a correct
one at that) this code should hopefully be no longer needed.
It's possible of course that other parts of the debug info are also
relying on the debug locations being set here to leak to where they're
needed - so we might see the same assertions again & will have to
investigate what the dependence was/is. But the chances are good that
any of those are debug info line table quality bugs we've just not found
yet anyway - so it'll be good to flush them out.
llvm-svn: 226383
 |