Jeff Law <jeffreya...@gmail.com> writes:
> On 4/5/23 10:48, Jakub Jelinek wrote:
>> On Wed, Apr 05, 2023 at 10:17:59AM -0600, Jeff Law wrote:
>>>> It is true that an instruction like
>>>> (insn 8 7 9 2 (set (reg:HI 141)
>>>> (subreg:HI (reg:SI 142) 0)) "aauu.c":6:18 181 {*movhi_internal}
>>>> (nil))
>>>> can appear in the IL on WORD_REGISTER_OPERATIONS target, but I think the
>>>> upper bits shouldn't be random garbage in that case, it should be zero
>>>> extended or sign extended.
>>> Well, that's one of the core questions here. What are the state of the
>>> upper 16 bits of (reg:HI 141)? The WORD_REGISTER_OPERATIONS docs aren't
>>> 100% clear as we're not really doing any operation.
>>>
>>> So again, I think we need to decide if the DSE transformation is correct or
>>> not. I *think* we can aggree that insn 39 is OK. It's really the semantics
>>> of insn 47 that I think we need to agree on. What is the state of the upper
>>> 16 bits of (reg:HI 175) after insn 47?
>>
>> I'm afraid I don't know the answers here, I think Eric is
>> WORD_REGISTER_OPERATIONS expert here I think these days (most of the major
>> targets are !WORD_REGISTER_OPERATIONS).
> Hopefully he'll chime in.
Just curious: have you experimented with making RISC-V
!WORD_REGISTER_OPERATIONS too? Realise it's not the right way
to fix the bug, just curious in general.
Not defining it seems to have worked well for AArch64. And IMO
the semantics are much easier to follow when there is no special
treatment of upper bits. Subregs are hard enough to reason about
as it is...
Richard
