[llvm-dev] New atomic handling status

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] New atomic handling status

Jeremy Morse via llvm-dev
Hi,

What is the current status of the new atomic load/store lowering started in https://reviews.llvm.org/D69219? The main reason atomic stores currently don’t work in GlobalISel is because the operands for atomic store are backwards from a regular store. Can we invert the operand order of the pattern nodes yet? That would avoid the need to handle the special case in TableGen.

-Matt

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] New atomic handling status

Jeremy Morse via llvm-dev
In short, I hit a major stumbling block.  I hadn't account for the fact
that some atomic stores dependent on element type (float vs int for
instance) for legality.

I've also been pulled away from working on this.  We should probably
revert a bunch of the changes until I get a chance to restart this as it
will require a redo on the design anyways. (Note that default behavior
is not effected, this is all under a flag for the moment.)

Philip

On 1/22/20 5:35 AM, Matt Arsenault wrote:

> Hi,
>
> What is the current status of the new atomic load/store lowering
> started in https://reviews.llvm.org/D69219? The main reason atomic
> stores currently don’t work in GlobalISel is because the operands for
> atomic store are backwards from a regular store. Can we invert the
> operand order of the pattern nodes yet? That would avoid the need to
> handle the special case in TableGen.
>
> -Matt
_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] New atomic handling status

Jeremy Morse via llvm-dev


On Jan 22, 2020, at 19:49, Philip Reames <[hidden email]> wrote:

In short, I hit a major stumbling block.  I hadn't account for the fact that some atomic stores dependent on element type (float vs int for instance) for legality.

I think this qualifies as a target/infrastructure bug. It should always be legal to cast the FP atomic load/store to integer. This distinction isn’t possible in GlobalISel, so it makes sense to move away from this being a situation to deal with.

-Matt

_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] New atomic handling status

Jeremy Morse via llvm-dev

PPC64 doesn’t have 32-bit floating point values in registers, they are always 64-bit.  32-bit FP loads/stores perform implicit conversions to/from 64-bit FP.  In such cases it’s not legal to do a bitcast to a 32-bit integer for the purpose of storing.

 

 

--

Krzysztof Parzyszek  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Matt Arsenault via llvm-dev
Sent: Monday, February 24, 2020 1:30 PM
To: Philip Reames <[hidden email]>
Cc: llvm-dev <[hidden email]>
Subject: [EXT] Re: [llvm-dev] New atomic handling status

 

 



On Jan 22, 2020, at 19:49, Philip Reames <[hidden email]> wrote:

 

In short, I hit a major stumbling block.  I hadn't account for the fact that some atomic stores dependent on element type (float vs int for instance) for legality.

 

I think this qualifies as a target/infrastructure bug. It should always be legal to cast the FP atomic load/store to integer. This distinction isn’t possible in GlobalISel, so it makes sense to move away from this being a situation to deal with.

 

-Matt


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] New atomic handling status

Jeremy Morse via llvm-dev

We can always lower “bitcast float %f to i32” using a stack temporary.  This lowering is used on multiple targets, including x86 without SSE.

 

-Eli

 

From: llvm-dev <[hidden email]> On Behalf Of Krzysztof Parzyszek via llvm-dev
Sent: Monday, February 24, 2020 11:41 AM
To: Matt Arsenault <[hidden email]>; Philip Reames <[hidden email]>; [hidden email]
Subject: [EXT] Re: [llvm-dev] New atomic handling status

 

PPC64 doesn’t have 32-bit floating point values in registers, they are always 64-bit.  32-bit FP loads/stores perform implicit conversions to/from 64-bit FP.  In such cases it’s not legal to do a bitcast to a 32-bit integer for the purpose of storing.

 

 

--

Krzysztof Parzyszek  [hidden email]   AI tools development

 

From: llvm-dev <[hidden email]> On Behalf Of Matt Arsenault via llvm-dev
Sent: Monday, February 24, 2020 1:30 PM
To: Philip Reames <[hidden email]>
Cc: llvm-dev <[hidden email]>
Subject: [EXT] Re: [llvm-dev] New atomic handling status

 

 

 

On Jan 22, 2020, at 19:49, Philip Reames <[hidden email]> wrote:

 

In short, I hit a major stumbling block.  I hadn't account for the fact that some atomic stores dependent on element type (float vs int for instance) for legality.

 

I think this qualifies as a target/infrastructure bug. It should always be legal to cast the FP atomic load/store to integer. This distinction isn’t possible in GlobalISel, so it makes sense to move away from this being a situation to deal with.

 

-Matt


_______________________________________________
LLVM Developers mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev