On 10/24/23 22:01, Vineet Gupta wrote:
RV64 comapre and branch instructions only support 64-bit operands.
The backend unconditionally generates zero/sign extend at Expand time
for compare and branch operands even if they are already as such
e.g. function args which ABI guarantees to be sign-exten
On 10/25/23 06:52, Jeff Law wrote:
On 10/25/23 07:47, Robin Dapp wrote:
Well, it doesn't seem like there's a lot of difference between doing
it in the generic expander bits vs target expander bits -- the former
just calls into the latter for the most part. Thus if the
subreg-promoted stat
On 10/25/23 09:30, Jeff Law wrote:
- Should some common-code part be more suited to handle that?
We already elide redundant sign-zero extensions for other
reasons. Maybe we could add subreg promoted handling there?
Not in the context of this specific issue.
Robin's point (IIUC) is
On 10/25/23 10:25, Vineet Gupta wrote:
Hey Robin,
On 10/25/23 00:12, Robin Dapp wrote:
Hi Vineet,
I was thinking of two things while skimming the code:
- Couldn't we do this in the expanders directly? Or is the
subreg-promoted info gone until we reach that?
Following is the call s
Hey Robin,
On 10/25/23 00:12, Robin Dapp wrote:
Hi Vineet,
I was thinking of two things while skimming the code:
- Couldn't we do this in the expanders directly? Or is the
subreg-promoted info gone until we reach that?
Following is the call stack involved:
expand_gimple_cond
do
On 10/25/23 07:47, Robin Dapp wrote:
Well, it doesn't seem like there's a lot of difference between doing
it in the generic expander bits vs target expander bits -- the former
just calls into the latter for the most part. Thus if the
subreg-promoted state is available in the target expander
> Well, it doesn't seem like there's a lot of difference between doing
> it in the generic expander bits vs target expander bits -- the former
> just calls into the latter for the most part. Thus if the
> subreg-promoted state is available in the target expander, I'd expect
> it to be available
On 10/25/23 01:12, Robin Dapp wrote:
Hi Vineet,
I was thinking of two things while skimming the code:
- Couldn't we do this in the expanders directly? Or is the
subreg-promoted info gone until we reach that?
Well, it doesn't seem like there's a lot of difference between doing it
in t
Hi Vineet,
I was thinking of two things while skimming the code:
- Couldn't we do this in the expanders directly? Or is the
subreg-promoted info gone until we reach that?
- Should some common-code part be more suited to handle that?
We already elide redundant sign-zero extensions for ot
RV64 comapre and branch instructions only support 64-bit operands.
The backend unconditionally generates zero/sign extend at Expand time
for compare and branch operands even if they are already as such
e.g. function args which ABI guarantees to be sign-extended (at callsite).
And subsequently REE
10 matches
Mail list logo
