Revert r236128, LLVM isn't falling back in the right way

llvm-svn: 236167

Re-land r236052, the linker errors were fixed by LLVM r236123

Basic __finally blocks don't cause linker errors anymore (although they
are miscompiled).

llvm-svn: 236128

Revert r236052, it caused linker errors when building 32-bit applications.

llvm-svn: 236082

[SEH] Add 32-bit lowering code for __try

This is just the clang-side of 32-bit SEH. LLVM still needs work, and it
will determinstically fail to compile until it's feature complete.

On x86, all outl

[SEH] Add 32-bit lowering code for __try

This is just the clang-side of 32-bit SEH. LLVM still needs work, and it
will determinstically fail to compile until it's feature complete.

On x86, all outlined handlers have no parameters, but they do implicitly
take the EBP value passed in and use it to address locals of the parent
frame. We model this with llvm.frameaddress(1).

This works (mostly), but __finally block inlining can break it. For now,
we apply the 'noinline' attribute. If we really want to inline __finally
blocks on 32-bit x86, we should teach the inliner how to untangle
frameescape and framerecover.

Promote the error diagnostic from codegen to sema. It now rejects SEH on
non-Windows platforms. LLVM doesn't implement SEH on non-x86 Windows
platforms, but there's nothing preventing it.

llvm-svn: 236052

show more ...

InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)

The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses else

InstrProf: Stop using RegionCounter outside of CodeGenPGO (NFC)

The RegionCounter type does a lot of legwork, but most of it is only
meaningful within the implementation of CodeGenPGO. The uses elsewhere
in CodeGen generally just want to increment or read counters, so do
that directly.

llvm-svn: 235664

show more ...

Revert "Revert r234581, it might have caused a few miscompiles in Chromium."

This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug whi

Revert "Revert r234581, it might have caused a few miscompiles in Chromium."

This reverts commit r234700. It turns out that the lifetime markers
were not the cause of Chromium failing but a bug which was uncovered by
optimizations exposed by the markers.

llvm-svn: 235553

show more ...

Reland r234613 (and follow-ups 234614, 234616, 234618)

The frameescape intrinsic cannot be inlined, so I fixed the inliner in
r234937. This should address PR23216.

llvm-svn: 234942

Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.

llvm-svn: 234789

Revert r234786, it contained a bunch of stuff I did not mean to commit.

llvm-svn: 234787

Revert r234613 (and follow-ups 234614, 234616, 234618), it caused PR23216.

llvm-svn: 234786

Revert r234581, it might have caused a few miscompiles in Chromium.

If the revert helps, I'll get a repro this Monday. Else I'll put the change
back in.

llvm-svn: 234700

[SEH] Re-land r234532, but use internal linkage for all SEH helpers

Even though these symbols are in a comdat group, the Microsoft linker
really wants them to have internal linkage.

I'm planning to

[SEH] Re-land r234532, but use internal linkage for all SEH helpers

Even though these symbols are in a comdat group, the Microsoft linker
really wants them to have internal linkage.

I'm planning to tweak the mangling in a follow-up change. This is a
straight revert with a 1-line fix.

llvm-svn: 234613

show more ...

Remove threshold for inserting lifetime markers for named temporaries

Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be remove

Remove threshold for inserting lifetime markers for named temporaries

Now that TailRecursionElimination has been fixed with r222354, the
threshold on size for lifetime marker insertion can be removed. This
only affects named temporary though, as the patch for unnamed temporaries
is still in progress.

My previous commit (r222993) was not handling debuginfo correctly, but
this could only be seen with some asan tests. Basically, lifetime markers
are just instrumentation for the compiler's usage and should not affect
debug information; however, the cleanup infrastructure was assuming it
contained only destructors, i.e. actual code to be executed, and was
setting the breakpoint for the end of the function to the closing '}', and
not the return statement, in order to show some destructors have been
called when leaving the function. This is wrong when the cleanups are only
lifetime markers, and this is now fixed.

llvm-svn: 234581

show more ...

Revert r234532 for a bit, it very likely caused http://crbug.com/475768

llvm-svn: 234563

[SEH] Outline finally blocks using the new variable capture support

WinEHPrepare was going to have to pattern match the control flow merge
and split that the old lowering used, and that wasn't reall

[SEH] Outline finally blocks using the new variable capture support

WinEHPrepare was going to have to pattern match the control flow merge
and split that the old lowering used, and that wasn't really feasible.

Now we can teach WinEHPrepare to pattern match this, which is much
simpler:
%fp = call i8* @llvm.frameaddress(i32 0)
call void @func(iN [01], i8* %fp)

This prototype happens to match the prototype used by the Win64 SEH
personality function, so this is really simple.

llvm-svn: 234532

show more ...

Process the -freciprocal-math optimization flag (PR20912)

The driver currently accepts but ignores the -freciprocal-math flag.
This patch passes the flag through and enables 'arcp' fast-math-flag
ge

Process the -freciprocal-math optimization flag (PR20912)

The driver currently accepts but ignores the -freciprocal-math flag.
This patch passes the flag through and enables 'arcp' fast-math-flag
generation in IR.

Note that this change does not actually enable the optimization for
any target. The reassociation optimization that this flag specifies
was implemented by http://reviews.llvm.org/D6334 :
http://llvm.org/viewvc/llvm-project?view=revision&revision=222510

Because the optimization is done in the backend rather than IR,
the backend must be modified to understand instruction-level
fast-math-flags or a new function-level attribute must be created.

Also note that -freciprocal-math is independent of any target-specific
usage of reciprocal estimate hardware instructions. That requires
its own flag ('-mrecip').

https://llvm.org/bugs/show_bug.cgi?id=20912

llvm-svn: 234493

show more ...

Reland "[SEH] Implement filter capturing in CodeGen"

The test should be fixed. It was failing in NDEBUG builds due to a
missing '*' character in a regex. In asserts builds, the pattern matched
a sin

Reland "[SEH] Implement filter capturing in CodeGen"

The test should be fixed. It was failing in NDEBUG builds due to a
missing '*' character in a regex. In asserts builds, the pattern matched
a single digit value, which became a double digit value in NDEBUG
builds. Go figure.

This reverts commit r234261.

llvm-svn: 234447

show more ...

Revert "[SEH] Implement filter capturing in CodeGen"

Test fails:
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/3182/

llvm-svn: 234306

[SEH] Implement filter capturing in CodeGen

While capturing filters aren't very common, we'd like to outline
__finally blocks in the frontend to simplify -O0 EH preparation and
reduce code size. Fin

[SEH] Implement filter capturing in CodeGen

While capturing filters aren't very common, we'd like to outline
__finally blocks in the frontend to simplify -O0 EH preparation and
reduce code size. Finally blocks are usually have captures, and this is
the first step towards that.

Currently we don't support capturing 'this' or VLAs.

Reviewers: majnemer

Differential Revision: http://reviews.llvm.org/D8825

llvm-svn: 234261

show more ...

[opaque pointer type] More GEP API migrations

Looks like the VTable code in particular will need some work to pass
around the pointee type explicitly.

llvm-svn: 234128

[opaque pointer type] more GEP API migrations

llvm-svn: 234097

C++14: Disable sized deallocation by default due to ABI breakage

There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they w

C++14: Disable sized deallocation by default due to ABI breakage

There are no widely deployed standard libraries providing sized
deallocation functions, so we have to punt and ask the user if they want
us to use sized deallocation. In the future, when such libraries are
deployed, we can teach the driver to detect them and enable this
feature.

N3536 claimed that a weak thunk from sized to unsized deallocation could
be emitted to avoid breaking backwards compatibility with standard
libraries not providing sized deallocation. However, this approach and
other variations don't work in practice.

With the weak function approach, the thunk has to have default
visibility in order to ensure that it is overridden by other DSOs
providing sized deallocation. Weak, default visibility symbols are
particularly expensive on MachO, so John McCall was considering
disabling this feature by default on Darwin. It also changes behavior
ELF linking behavior, causing certain otherwise unreferenced object
files from an archive to be pulled into the link.

Our second approach was to use an extern_weak function declaration and
do an inline conditional branch at the deletion call site. This doesn't
work because extern_weak only works on MachO if you have some archive
providing the default value of the extern_weak symbol. Arranging to
provide such an archive has the same challenges as providing the symbol
in the standard library. Not to mention that extern_weak doesn't really
work on COFF.

Reviewers: rsmith, rjmccall

Differential Revision: http://reviews.llvm.org/D8467

llvm-svn: 232788

show more ...

Remove .CUDAIsDevice flags from CodeGenOpts as it's already
available in LangOpts.

Differential Revision: http://reviews.llvm.org/D8385

llvm-svn: 232749

[OPENMP] Rename methods of OpenMPRuntime class. NFC.

llvm-svn: 230470

Avoid using a COMDAT for sized delete on MachO

llvm-svn: 229915