> 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>
Krzysztof Parzyszek via llvm-dev
2020-Feb-24 19:41 UTC
[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 kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Matt Arsenault via llvm-dev Sent: Monday, February 24, 2020 1:30 PM To: Philip Reames <listmail at philipreames.com> Cc: llvm-dev <llvm-dev at lists.llvm.org> Subject: [EXT] Re: [llvm-dev] New atomic handling status On Jan 22, 2020, at 19:49, Philip Reames <listmail at philipreames.com<mailto: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/0be13b69/attachment.html>
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 <llvm-dev-bounces at lists.llvm.org> On Behalf Of Krzysztof Parzyszek via llvm-dev Sent: Monday, February 24, 2020 11:41 AM To: Matt Arsenault <arsenm2 at gmail.com>; Philip Reames <listmail at philipreames.com>; llvm-dev at lists.llvm.org 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 kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development From: llvm-dev <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org>> On Behalf Of Matt Arsenault via llvm-dev Sent: Monday, February 24, 2020 1:30 PM To: Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> Cc: llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> Subject: [EXT] Re: [llvm-dev] New atomic handling status On Jan 22, 2020, at 19:49, Philip Reames <listmail at philipreames.com<mailto: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/0404610c/attachment.html>