Displaying 20 results from an estimated 1100 matches similar to: "Incorrect code generation when using -fprofile-generate on code which contains exception handling (Windows target)"
2020 Jan 14
2
Incorrect code generation when using -fprofile-generate on code which contains exception handling (Windows target)
I think the simplest, most complete, short term fix, would be to call
llvm::colorEHFunclets, and to have the relevant instrumentation passes
apply the appropriate funclet bundle when inserting function calls. It's
not elegant because it means every simple instrumentation pass that inserts
regular function calls (ASan, TSan, MSan, instrprof, etc) needs to be
funclet-aware. But, it will work,
2018 May 22
2
LLVM SEH docs -- enregistration of locals in nonvolatile registers?
https://llvm.org/docs/ExceptionHandling.html#wineh
> No variables live in to or out of the funclet can be allocated in registers.
I don't think this is quite true. though it might be a useful simplification.
Obviously it is true for volatile registers, but I believe the funclet receives a CONTEXT
with the nonvolatiles restored. Obviously cumbersome to access, but it lets you enregister
2018 May 24
0
LLVM SEH docs -- enregistration of locals in nonvolatile registers?
Is this example what you had in mind?
void f() {
int *p = get_p();
use_p(p);
try {
may_throw(p);
} catch (int) {
// don't need p
}
use_p(p);
}
The idea is that because p is not modified or used within the catch region
(the funclet), it can live in a callee-saved register across the whole
function.
That is true, it is possible, but I don't think it fits very well in
2015 May 19
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
I think adding transitions to cleanupblocks on the normal execution path
would be an optimization barrier. Most passes would see the cleanupblock
instruction and run the other way. It's definitely appealing from the
perspective of getting the smallest possible code, but I'm OK with having
no more than two copies of everything in the finally block.
I think with the addition of the
2015 May 20
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
This example is pretty compelling, but I still think I want to limit the
scope of this change to not include this feature. It's probably reasonable
to hold onto the idea as future work, though. In the meantime, frontends
can decide for themselves whether they want code size or stronger
optimization of cleanups by doing early outlining or not.
The only way we can hit the quadratic growth from
2015 May 19
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
On Mon, May 18, 2015 at 8:40 PM, Joseph Tremoulet <jotrem at microsoft.com>
wrote:
> > I want to have separate normal and exceptional codepaths
>
> I assume you at least mean that's what you'll be doing in Clang's initial
> IR generation. Do you also mean to impose this as a restriction on other
> IR generators, and as a property that IR transformations must
2015 May 18
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
On Mon, May 18, 2015 at 12:03 PM, Joseph Tremoulet <jotrem at microsoft.com>
wrote:
> Hi,
>
>
>
> Thanks for sending this out. We're looking forward to seeing this come
> about, since we need funclet separation for LLILC as well (and I have
> cycles to spend on it, if that would be helpful).
>
>
>
> Some questions about the new proposal:
>
>
>
2017 Jan 05
2
WinEH funclet coloring in computeLoopSafetyInfo
I've been looking at compilation time issues in the LICM pass, and it looks to me like colorEHFunclets() is probably being called a lot more often than it needs to be for functions that have Windows EH personality functions. For one thing, the funclet coloring is happening when computeLoopSafetyInfo() is called from LoopIdiomRecognize and LoopUnswitch but those passes don't use the
2015 May 15
8
[LLVMdev] RFC: New EH representation for MSVC compatibility
After a long tale of sorrow and woe, my colleagues and I stand here before
you defeated. The Itanium EH representation is not amenable to implementing
MSVC-compatible exceptions. We need a new representation that preserves
information about how try-catch blocks are nested.
WinEH background
-------------------------------
Skip this if you already know a lot about Windows exceptions. On Windows,
2019 Jun 25
3
Potential missed optimisation with SEH funclets
I’ve been experimenting with SEH handling in LLVM, and it seems like the unwind funclets generated by LLVM are much larger than those generated by Microsoft’s CL compiler.
I used the following code as a test:
void test() {
MyClass x;
externalFunction();
}
Compiling with CL, the unwind funclet that destroys ‘x’ is just two lines of asm:
lea rcx, QWORD PTR x$[rdx]
jmp ??1MyClass@@QEAA at XZ
2016 Apr 04
2
How to call an (x86) cleanup/catchpad funclet
I've modified llvm to emit vc++ compatible SEH structures for my
personality on x86/Windows and my handler works fine, but the only thing
I can't figure out is how to call these funclets, they look like:
Catch:
"?catch$3@?0?m3 at 4HA":
LBB4_3: # %BasicBlock26
pushl %ebp
pushl %eax
addl $12, %ebp
movl %esp, -28(%ebp)
movl $LBB4_5, %eax
2006 Apr 07
3
Pointer position on keypress event?
Hi.
Is there any straightforward way to tell pointer position (x, y)
upon keypress? In original wxWidgets, wxKeyEvent supports GetX()
and GetY() methods, but wxRuby''s KeyEvent object does not have
one. I also checked with event.methods and event.instance_variables.
Do I need to keep track of pointer position by evt_motion?
--
Taisuke Yamada <tyamadajp@spam.rakugaki.org>,
2020 Jun 25
2
[RFC] Replacing inalloca with llvm.call.setup and preallocated
Bringing this back up for discussion on handling exceptions.
According to the inalloca design <https://llvm.org/docs/InAlloca.html>,
there should be a stackrestore after an invoke in both the non-exceptional
and exceptional case (that doesn't seem to be happening in some cases as
we've seen, but that's beside the point).
Does it make sense to model a preallocated call as
2015 Apr 16
2
[LLVMdev] Exception filter IR model
Hi,
I have a question about the IR model for SEH filters (as I want to use the same model for CLR filters). In particular, when an outer filter is invoked before entering an inner finally, which piece of IR reflects the filter's side-effects? To take a concrete example, consider this C code:
void foo() {
int x;
__try {
x = 0;
__try {
x = 2;
may_throw();
}
2020 Jan 26
2
[RFC] Replacing inalloca with llvm.call.setup and preallocated
Hello all,
A few years ago, I added the inalloca feature to LLVM IR so that Clang
could be C++ ABI compatible with MSVC on 32-bit x86. The feature works, but
there is room for improvement. I recently took the time to write up a
design using token values that will hopefully be better named and easier to
work with and around.
For the technical details of the proposal, I've written up the RFC
2020 Apr 01
2
[RFC] [Windows SEH] Local_Unwind (Jumping out of a _finally) and -EHa (Hardware Exception Handling)
Hi, all,
The intend of this thread is to complete the support for Windows SEH.
Currently there are two major missing features: Jumping out of a _finally and Hardware exception handling.
The document below is my proposed design and implementation to fully support SEH on LLVM.
I have completely implemented this design on a branch in repo:
2016 Jul 16
2
RFC: Strong GC References in LLVM
Hi Andy,
Andrew Trick wrote:
> At some point I stopped thinking about this as a bug and realized that
> you just need to think of LLVM as modeling speculative code barriers as
> memory dependence. In LLVM, it makes no sense to have a readonly
> may-throw call.
The problem is that that model breaks down with aggressive aliasing
like:
void foo(int* restrict ptr) {
*ptr = 40;
2015 May 18
2
[LLVMdev] RFC: New EH representation for MSVC compatibility
On Sat, May 16, 2015 at 7:29 AM, Steve Cheng <steve.ckp at gmail.com> wrote:
> On 2015-05-15 18:37:58 -0400, Reid Kleckner said:
>
> After a long tale of sorrow and woe, my colleagues and I stand here
>> before you defeated. The Itanium EH representation is not amenable to
>> implementing MSVC-compatible exceptions. We need a new representation that
>> preserves
2020 Apr 28
2
Android kernel PGO with LLVM
Hello,
I'm working on Android kernel profile-guided optimization to figure out
whether pgo can improve the performance of Android kernel. I have tried
to added '-fprofile-generate' option to build Android kernel(msm-4.19).
But error occurs during building: "undefined reference to
'__llvm_profile_instrument_target'".
I have tried to add
2015 Jun 17
2
[LLVMdev] RFC - Stop ignoring -fprofile-generate and -fprofile-use
The flags -fprofile-generate and -fprofile-use are currently ignored for
GCC compatibility. I would like to enable them and give them similar
semantics to GCC. These flags are baked pretty deeply into our build
environment, so supporting them at the driver level will make our lives a
lot simpler.
>From https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html: