Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 2/4/24 9:58 PM, Jeff Law wrote: On 2/2/24 15:48, Greg McGary wrote: input: (sign_extend:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86] ) [1 minus_1+0 S4 A32])) result: (subreg:DI (mem/c:SI (symbol_ref:DI ("minus_1") [flags 0x86] ) [1 minus_1+0 S4 A32]) 0) Later, the high part

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 2/2/24 15:48, Greg McGary wrote: On 2/1/24 10:24 PM, Jeff Law wrote: On 2/1/24 18:24, Greg McGary wrote: However, for a machine where (WORD_REGISTER_OPERATIONS && load_extend_op (inner_mode) == SIGN_EXTEND), the high part of a PSoM is  only known at runtime as 0s or 1s. That's the

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 2/1/24 10:24 PM, Jeff Law wrote: On 2/1/24 18:24, Greg McGary wrote: However, for a machine where (WORD_REGISTER_OPERATIONS && load_extend_op (inner_mode) == SIGN_EXTEND), the high part of a PSoM is  only known at runtime as 0s or 1s. That's the downstream bug. The fix for such machines

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 2/1/24 18:24, Greg McGary wrote: On 1/18/24 9:24 AM, Jeff Law wrote: On 1/17/24 20:53, Greg McGary wrote: While the code comment is true, perhaps it obscures the primary intent, which is recognition that the pattern (SIGN_EXTEND (mem ...) ) is destined to expand into a single

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 1/18/24 9:24 AM, Jeff Law wrote: On 1/17/24 20:53, Greg McGary wrote: While the code comment is true, perhaps it obscures the primary intent, which is recognition that the pattern (SIGN_EXTEND (mem ...) ) is destined to expand into a single memory-load instruction and no simplification

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On 1/17/24 20:53, Greg McGary wrote: On Tue, Jan 16, 2024 at 11:44 PM Richard Biener mailto:richard.guent...@gmail.com>> wrote: > On Tue, Jan 16, 2024 at 11:20 PM Greg McGary > wrote: > > > > The sign bit of a sign-extending load cannot be known until

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On Tue, Jan 16, 2024 at 11:44 PM Richard Biener wrote: > > On Tue, Jan 16, 2024 at 11:20 PM Greg McGary wrote: > > > > > > The sign bit of a sign-extending load cannot be known until runtime, > > > so don't attempt to simplify it in the combiner. > > > It feels like this papers over an

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

Greg McGary 于2024年1月17日周三 06:20写道： > > The sign bit of a sign-extending load cannot be known until runtime, > so don't attempt to simplify it in the combiner. > > 2024-01-11 Greg McGary > > PR rtl-optimization/113010 > * combine.cc (expand_compound_operation): Don't simplify >

Re: [PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

On Tue, Jan 16, 2024 at 11:20 PM Greg McGary wrote: > > The sign bit of a sign-extending load cannot be known until runtime, > so don't attempt to simplify it in the combiner. It feels like this papers over an issue downstream? > 2024-01-11 Greg McGary > > PR rtl-optimization/113010

[PATCH] combine: Don't optimize SIGN_EXTEND of MEM on WORD_REGISTER_OPERATIONS targets [PR113010]

The sign bit of a sign-extending load cannot be known until runtime, so don't attempt to simplify it in the combiner. 2024-01-11 Greg McGary PR rtl-optimization/113010 * combine.cc (expand_compound_operation): Don't simplify SIGN_EXTEND of a MEM on