I was looking into this yesterday but I ran into some issues.
The first is that blindly converting each output to in+out breaks
cases where an input already overlaps with an output:
asm ("..." : "=r" (out) : "0" (in));
This could be worked around by scanning the input list and only
converting
On 2020-03-19 18:06, Michael Matz wrote:
> Hello,
>
> On Wed, 18 Mar 2020, J.W. Jagersma via Gcc-patches wrote:
>
>>> Well, it's both: on the exception path the compiler has to assume that the
>>> the value wasn't changed (so that former defines are regarded as dead) or
>>> that it already has
Hello,
On Thu, 19 Mar 2020, J.W. Jagersma via Gcc-patches wrote:
> I just realized that changing all outputs to in+out would generate
> worse code for *every* single asm that has any outputs.
Under -fnon-call-exception only. And I'm not sure what you mean, the only
effect of the additional 'in
Hello,
On Wed, 18 Mar 2020, J.W. Jagersma via Gcc-patches wrote:
> > Well, it's both: on the exception path the compiler has to assume that the
> > the value wasn't changed (so that former defines are regarded as dead) or
> > that it already has changed (so that the effects the throwing
> > "i
On 2020-03-19 00:56, Segher Boessenkool wrote:
> On Tue, Mar 17, 2020 at 03:32:34PM +, Michael Matz wrote:
>> On Mon, 16 Mar 2020, Richard Sandiford wrote:
>>> Similarly for non-call exceptions on other statements. It sounds like
>>> what you're describing requires the corresponding definitio
Hello,
On Wed, 18 Mar 2020, Segher Boessenkool wrote:
> > > Similarly for non-call exceptions on other statements. It sounds like
> > > what you're describing requires the corresponding definition to happen
> > > for memory outputs regardless of whether the asm throws or not, so that
> > > th
On Tue, Mar 17, 2020 at 03:32:34PM +, Michael Matz wrote:
> On Mon, 16 Mar 2020, Richard Sandiford wrote:
> > Similarly for non-call exceptions on other statements. It sounds like
> > what you're describing requires the corresponding definition to happen
> > for memory outputs regardless of
Hi Michael, thanks for your response.
On 2020-03-17 16:32, Michael Matz wrote:
> Hello,
>
> On Mon, 16 Mar 2020, Richard Sandiford wrote:
>
>> Segher Boessenkool writes:
>>> On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote:
Segher Boessenkool writes:
>> we do delete "
Hello,
On Mon, 16 Mar 2020, Richard Sandiford wrote:
> Segher Boessenkool writes:
> > On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote:
> >> Segher Boessenkool writes:
> >> >> we do delete "x = 1" for f1. I think that's the expected behaviour.
> >> >> We don't yet delete the
On Mon, Mar 16, 2020 at 07:46:57PM +, Richard Sandiford wrote:
> > The write to "x" *before the asm* is deleted. I cannot think of any
> > interpretation where that is correct (this does not involve inline asm
> > at all: it is deleting an observable side effect before the exception).
>
> It'
Segher Boessenkool writes:
> On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote:
>> Segher Boessenkool writes:
>> >> we do delete "x = 1" for f1. I think that's the expected behaviour.
>> >> We don't yet delete the initialisation in f2, but I think in principle
>> >> we could.
>>
On Mon, Mar 16, 2020 at 05:47:03PM +, Richard Sandiford wrote:
> Segher Boessenkool writes:
> >> we do delete "x = 1" for f1. I think that's the expected behaviour.
> >> We don't yet delete the initialisation in f2, but I think in principle
> >> we could.
> >
> > Right. And this is incorrec
Segher Boessenkool writes:
> On Fri, Mar 13, 2020 at 01:31:19PM +, Richard Sandiford wrote:
>> This might not be what you mean, but for:
>>
>> int
>> f1 (void)
>> {
>> int x = 1;
>> asm volatile ("": "=m" (x));
>> return x;
>> }
>>
>> struct s { int i[5]; };
>> struct s
>> f2 (void)
>>
On 2020-03-13 14:31, Richard Sandiford wrote:
> "J.W. Jagersma" writes:
>> On 2020-03-12 10:59, Richard Sandiford wrote:
>>> The other case I mentioned was equivalent to:
>>>
>>> int
>>> test_mem2 ()
>>> {
>>>int i = 2;
>>>try
>>> {
>>>asm volati
On Fri, Mar 13, 2020 at 02:06:13AM +0100, J.W. Jagersma wrote:
> I don't want to unnecessarily pessimize register outputs if it can be
> avoided. And even if you do change register outputs to in+out, they
> are still more likely to contain some intermediate value that you would
> want to discard o
Hi!
On Fri, Mar 13, 2020 at 01:31:19PM +, Richard Sandiford wrote:
> This might not be what you mean, but for:
>
> int
> f1 (void)
> {
> int x = 1;
> asm volatile ("": "=m" (x));
> return x;
> }
>
> struct s { int i[5]; };
> struct s
> f2 (void)
> {
> struct s x = { 1, 2, 3, 4, 5 };
"J.W. Jagersma" writes:
> On 2020-03-12 10:59, Richard Sandiford wrote:
>> The other case I mentioned was equivalent to:
>>
>> int
>> test_mem2 ()
>> {
>>int i = 2;
>>try
>> {
>>asm volatile ("ud2; mov%z0 $1, %0" : "=m" (i));
>> }
>>
On 2020-03-12 20:26, Segher Boessenkool wrote:
> On Thu, Mar 12, 2020 at 07:42:30PM +0100, J.W. Jagersma wrote:
>> On 2020-03-12 16:32, Segher Boessenkool wrote:
>>> On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote:
> It wasn't clear from my message above, but: I was mostly worrie
On 2020-03-12 10:59, Richard Sandiford wrote:
> The other case I mentioned was equivalent to:
>
> int
> test_mem2 ()
> {
>int i = 2;
>try
> {
>asm volatile ("ud2; mov%z0 $1, %0" : "=m" (i));
> }
>catch (const illegal_opcode&)
>
On Thu, Mar 12, 2020 at 07:42:30PM +0100, J.W. Jagersma wrote:
> On 2020-03-12 16:32, Segher Boessenkool wrote:
> > On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote:
> >>> It wasn't clear from my message above, but: I was mostly worried about
> >>> requiring the asm to treat memory op
On 2020-03-12 16:32, Segher Boessenkool wrote:
> On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote:
>>> It wasn't clear from my message above, but: I was mostly worried about
>>> requiring the asm to treat memory operands in a certain way when the
>>> exception is thrown. IMO it would
On Thu, Mar 12, 2020 at 02:08:18PM +0100, Richard Biener wrote:
> > It wasn't clear from my message above, but: I was mostly worried about
> > requiring the asm to treat memory operands in a certain way when the
> > exception is thrown. IMO it would be better to say that the values of
> > memory o
On Thu, Mar 12, 2020 at 11:01 AM Richard Sandiford
wrote:
>
> "J.W. Jagersma" writes:
> > On 2020-03-09 13:13, Richard Sandiford wrote:
> >> Thanks for doing this.
> >
> > Hi Richard, thanks for your response.
> >
> >> "J.W. Jagersma" writes:
> >>> On 2020-03-07 20:20, Segher Boessenkool wrote:
"J.W. Jagersma" writes:
> On 2020-03-09 13:13, Richard Sandiford wrote:
>> Thanks for doing this.
>
> Hi Richard, thanks for your response.
>
>> "J.W. Jagersma" writes:
>>> On 2020-03-07 20:20, Segher Boessenkool wrote:
Some comments:
> +When non-call exceptions (@option{-fnon-call-
On 2020-03-10 01:25, Segher Boessenkool wrote:
> On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote:
>> On 2020-03-09 19:01, Segher Boessenkool wrote:
>>> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
int foo = 0
try
{
On 2020-03-09 23:10, Segher Boessenkool wrote:
> Hi!
>
> On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote:
>> There is also still the question of whether non-volatile asms should be
>> allowed to throw or not. I don't know if that should be discussed here
>> or on the PR.
>
> I thin
On Mon, Mar 09, 2020 at 07:42:20PM +0100, J.W. Jagersma wrote:
> On 2020-03-09 19:01, Segher Boessenkool wrote:
> > On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
> >> int foo = 0
> >> try
> >> {
> >> asm volatile ("..." : "=r" (foo));
> >>
Hi!
On Sun, Mar 08, 2020 at 05:18:21PM +0100, J.W. Jagersma wrote:
> The only question I have left now is if my proposed change to the
> documentation is acceptable or should be expanded/reworded.
I think it is fine. It's easier to judge if you look fresh at it, in
my experience, so I might thin
On 2020-03-09 19:01, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
>> I think memory operands are fine - my original concern was about
>> register outputs and SSA form that should reflect the correct def
>> on the EH vs non-EH edge. From a "mi
Hi!
On Mon, Mar 09, 2020 at 01:54:53PM +0100, Richard Biener wrote:
> I think memory operands are fine - my original concern was about
> register outputs and SSA form that should reflect the correct def
> on the EH vs non-EH edge. From a "miscompile" perspective
> doing nothig which means pretend
On 2020-03-09 13:13, Richard Sandiford wrote:
> Thanks for doing this.
Hi Richard, thanks for your response.
> "J.W. Jagersma" writes:
>> On 2020-03-07 20:20, Segher Boessenkool wrote:
>>> Some comments:
>>>
+When non-call exceptions (@option{-fnon-call-exceptions}) are enabled, a
+@co
On Mon, Mar 9, 2020 at 1:14 PM Richard Sandiford
wrote:
>
> Thanks for doing this.
>
> "J.W. Jagersma" writes:
> > On 2020-03-07 20:20, Segher Boessenkool wrote:
> >> Hi!
> >>
> >> On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
> >>> The following patch extends the generation of e
Thanks for doing this.
"J.W. Jagersma" writes:
> On 2020-03-07 20:20, Segher Boessenkool wrote:
>> Hi!
>>
>> On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
>>> The following patch extends the generation of exception handling
>>> information to cover volatile asms too. This was a
On 2020-03-08 00:03, Segher Boessenkool wrote:
> On Sat, Mar 07, 2020 at 10:06:46PM +0100, J.W. Jagersma wrote:
>> Thanks Marek and Gerald, I hadn't read that page yet. So do I resubmit
>> the final patch during stage 1, or will it end up in a queue to be
>> included when stage 1 for gcc 11 (or 10
[ I didn't get any of the intervening replies, huh. ]
On Sat, Mar 07, 2020 at 10:06:46PM +0100, J.W. Jagersma wrote:
> On 2020-03-07 21:52, Gerald Pfeifer wrote:
> >On Sat, 7 Mar 2020, J.W. Jagersma wrote:
> >>>This should wait for stage 1, IMO. Looks pretty good to me, thanks!
> >>What does stag
On 2020-03-07 21:48, Marek Polacek wrote:
On Sat, Mar 07, 2020 at 09:43:59PM +0100, J.W. Jagersma wrote:
What does stage 1 refer to? I'm sorry, this is my first gcc patch and
I'm still learning how this all works.
No worries, you'll get there. You can read more about that here:
https://gcc.g
Hi J.W.,
On Sat, 7 Mar 2020, J.W. Jagersma wrote:
>> This should wait for stage 1, IMO. Looks pretty good to me, thanks!
> What does stage 1 refer to? I'm sorry, this is my first gcc patch and
> I'm still learning how this all works.
we have tried to cover this at https://gcc.gnu.org/develop.ht
On Sat, Mar 07, 2020 at 09:43:59PM +0100, J.W. Jagersma wrote:
> What does stage 1 refer to? I'm sorry, this is my first gcc patch and
> I'm still learning how this all works.
No worries, you'll get there. You can read more about that here:
https://gcc.gnu.org/develop.html
Marek
On 2020-03-07 20:20, Segher Boessenkool wrote:
Hi!
On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
The following patch extends the generation of exception handling
information to cover volatile asms too. This was already mostly
implemented, and only minor changes are required in
Hi!
On Sat, Mar 07, 2020 at 06:12:45PM +0100, J.W. Jagersma wrote:
> The following patch extends the generation of exception handling
> information to cover volatile asms too. This was already mostly
> implemented, and only minor changes are required in order to make it
> work.
This should wait
The following patch extends the generation of exception handling
information to cover volatile asms too. This was already mostly
implemented, and only minor changes are required in order to make it
work.
The new test case works for me on x86_64-linux-gnu, but will likely
fail on most other platfo
41 matches
Mail list logo
