On 06/26/2018 01:20 PM, Peryt, Sebastian wrote:
>> Subject: Re: Question regarding preventing optimizing out of register in
>> expansion
>>
>> On 6/26/18 4:05 AM, Peryt, Sebastian wrote:
>>> With some changes simplified implementation of my expansion is as follows:
>>> tmp_op0 = gen_reg_rtx (mode);
> Subject: Re: Question regarding preventing optimizing out of register in
> expansion
>
> On 6/26/18 4:05 AM, Peryt, Sebastian wrote:
> > With some changes simplified implementation of my expansion is as follows:
> > tmp_op0 = gen_reg_rtx (mode);
> > emit_move_insn (tmp_op0, op0);
>
> You set tm
On 6/26/18 4:05 AM, Peryt, Sebastian wrote:
> With some changes simplified implementation of my expansion is as follows:
> tmp_op0 = gen_reg_rtx (mode);
> emit_move_insn (tmp_op0, op0);
You set tmp_op0 here, and then
> emit_insn (gen_rtx_SET (tmp_op0, reg));
You set it again here without ev
On 06/26/2018 07:39 AM, Florian Weimer wrote:
On 06/26/2018 01:35 PM, Nathan Sidwell wrote:
IIRC, in gcc-land you have to give both noreturn and nothrow
attributes to make it non-unwindable.
Are you sure? I was under the impression that GCC did not do this
because it interferes too much wi
On Tue, Jun 26, 2018 at 01:39:18PM +0200, Florian Weimer wrote:
> > The @code{noreturn} keyword does not affect the exceptional path
> > when that applies: a @code{noreturn}-marked function may still
> > return to the caller by throwing an exception or calling
> > @code{longjmp}.
> >
> > IIRC, in
On 06/26/2018 01:35 PM, Nathan Sidwell wrote:
On 06/26/2018 07:21 AM, Florian Weimer wrote:
GCC doesn't do this AFAIK, but it's theoretically possible not to
preserve the return address for a noreturn function. But that would
be very bad for exception handling, so let's hope compilers don't d
On 06/26/2018 07:21 AM, Florian Weimer wrote:
GCC doesn't do this AFAIK, but it's theoretically possible not to
preserve the return address for a noreturn function. But that would be
very bad for exception handling, so let's hope compilers don't do this.
I'd forgotten about noreturn. Such f
On 06/26/2018 01:25 PM, Jakub Jelinek wrote:
On Tue, Jun 26, 2018 at 01:01:06PM +0200, Florian Weimer wrote:
On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to
ensure that the PC is a valid
On Tue, Jun 26, 2018 at 01:01:06PM +0200, Florian Weimer wrote:
> On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
> > On 06/26/2018 05:26 AM, Florian Weimer wrote:
> >
> > > So it looks to me that the caller of _Unwind_Find_FDE needs to
> > > ensure that the PC is a valid element of the call stack.
On 06/26/2018 01:15 PM, Nathan Sidwell wrote:
On 06/26/2018 07:01 AM, Florian Weimer wrote:
On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to
ensure that the PC is a valid element of the c
On 06/26/2018 07:01 AM, Florian Weimer wrote:
On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to ensure
that the PC is a valid element of the call stack. Is this a correct
assumption?
I
On 06/26/2018 12:56 PM, Nathan Sidwell wrote:
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to ensure
that the PC is a valid element of the call stack. Is this a correct
assumption?
I thought this was an (implicit?) requirement. Yo
On 06/26/2018 05:26 AM, Florian Weimer wrote:
So it looks to me that the caller of _Unwind_Find_FDE needs to ensure
that the PC is a valid element of the call stack. Is this a correct
assumption?
I thought this was an (implicit?) requirement. You're unwinding a stack
to deliver an exception
I'm looking at ways to speed up _Unwind_Find_FDE when libgcc is running
on top of glibc. I have something (at the design level, with some of
the code written) which allows me to get a pointer to the
PT_GNU_EH_FRAME segment in memory in a lock-free fashion (so it would
also be async-signal safe
After some more digging and adjusting I found additional cases that are
optimizing out registers
thus I decided to continue this thread to keep discussion compact.
With some changes simplified implementation of my expansion is as follows:
tmp_op0 = gen_reg_rtx (mode);
emit_move_insn (tmp_op0, op
15 matches
Mail list logo
