Displaying 20 results from an estimated 600 matches similar to: "Potential missed optimisation with SEH funclets"
2018 Feb 06
3
What does a dead register mean?
Hi,
My understanding of a "dead" register is a def that is never used. However,
when I dump the MI after reg alloc on a simple program I see the following
sequence:
ADJCALLSTACKDOWN64 0, 0, 0, *implicit-def dead %rsp*, implicit-def dead
%eflags, implicit-def dead %ssp, implicit %rsp, implicit %ssp
CALL64pcrel32 @foo, <regmask %bh %bl %bp %bpl %bx %ebp %ebx %rbp %rbx %r12
%r13 %r14
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
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
2020 Jan 13
2
Incorrect code generation when using -fprofile-generate on code which contains exception handling (Windows target)
I think this is the same underlying issue as https://bugs.llvm.org/show_bug.cgi?id=40320. CCing Reid, who's had a bunch of thoughts on this in the past.
On 1/11/20, 10:25 AM, "llvm-dev on behalf of Chrulski, Christopher M via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote:
Hi,
I've run into a bug with the LLVM
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,
2015 Oct 27
2
How to create global symbol from record offset
I would like to create something like this (x86_64)
.section __DATA,__data
.align 4
_a:
.long 18
.globl _b
_b:
.long 48
If you like to notice, there is no alignment between _a and _b.
_b is basically offseting into a record structure.
----
When I use two discrete structs, I get .aligns and I also don't trust
the tools to keep the two globals together.
%struct.a = type { i32 }
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
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
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 Jul 28
1
[LLVMdev] Adding a stack probe function attribute
On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com> wrote:
> On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker
> <john.mailinglists at gmail.com> wrote:
>>
>> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com> wrote:
>> > Yeah, the function attributes section of LangRef is a reasonable place
>> > to
>>
2015 Aug 16
2
[LLVMdev] Adding a stack probe function attribute
I started to implement inlining of the stack probe function based on
Microsoft's inlined stack probes in
https://github.com/Microsoft/llvm/tree/MS.
Do we know why the stack pointer cannot be updated in a loop (which
results in ideal code)? I noticed that was commented in Microsoft's
code.
I suspect this is due to debug or unwinding information, since it is
allowed on Windows x86-32.
I
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
2010 Dec 03
1
[LLVMdev] Alternative exception handling proposal
Hi Bill, there is clearly a misunderstanding: either I am missing something
essential or you are. To clear this up, I suggest you send me evil examples
and I will show you how my scheme handles them (or doesn't handle them, if I
am indeed failing to see something).
> This is the code that G++ generates from the example in my proposal:
...
> If the call to __Z3foov throws, we need to
2017 Nov 16
2
question about xray tls data initialization
I'm learning the xray library and try if it can be built on windows, in
xray_fdr_logging_impl.h
line 152 , comment written as
// Using pthread_once(...) to initialize the thread-local data structures
but at line 175, 183, code written as
thread_local pthread_key_t key;
// Ensure that we only actually ever do the pthread initialization once.
thread_local bool UNUSED Unused = [] {
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 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,
2017 Nov 21
2
question about xray tls data initialization
with some dirty hack , I've made xray runtime 'built' on windows ,
but unfortunately I haven't enough knowledge about linker and the
runtime, and finally built executable didn't run. I'd like to share
my changes here , hopes somebody help me to make it run on windows.
in AsmPrinter, copy/paster xray for coff target
InstMap =
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
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:
>
>
>
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