Hi, What is the current status of the new atomic load/store lowering started in https://reviews.llvm.org/D69219? <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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200122/e5a98f75/attachment-0001.html>
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
> On Jan 22, 2020, at 19:49, Philip Reames <listmail at philipreames.com> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200224/69d750fc/attachment.html>