CSE fold_rtx subreg patch
John Wehle
john@feith.com
Fri Jul 10 16:38:00 GMT 1998
> I note that "mode_arg" is used outside the switch statement -- do we
> need to fix it, or is its value correct?
Good point. We probably need to fix it if the substitution is performed.
> I'm also a little worried about the < to <= changes, particularly for
> SUBREGS since they are not optimized as well as REGs in other passes
> and thus "cost more". Presumably you added it because the cases you
> tried had equal cost.
>
> You might consider changing RTX_COSTS for the x86 to make SUBREGS
> which narrow an expression cheaper than the inner expression since
> narrowing may allow byte/half sized instructions to be used.
Are you refering to RTX_COSTS in the context of the < to <= change or in
general?
Regarding the < to <= change I don't believe that RTX_COSTS has an effect.
In the case of a SUBREG the COST macro calls notreg_cost which has a special
case for handling a SUBREG. It basicly uses the exact same logic for a SUBREG
as COST uses for a REG thus guarenteeing in the case at hand that the cost of
the SUBREG will always equal the cost of the REG.
In general I don't believe that it's possible for RTX_COSTS to handle
SUBREG since this already in the switch in which RTX_COSTS appears.
Should I resubmit this patch with the change to handle "mode_arg" or do
you suggest I take a different approach? My basic issue is that if
CSE is going to replace:
(insn 16 13 18 (set (mem:HI (symbol_ref:SI ("c")))
(reg/v:HI 23)) -1 (nil)
(nil))
with:
(insn 16 10 18 (set (mem:HI (symbol_ref:SI ("c")))
(subreg:HI (reg:SI 22) 0)) 57 {movhi+1} (nil)
(nil))
(which it currently does) then it should consider replacing the other
places in which (reg/v:HI 23) appears with (subreg:HI (reg:SI 22) 0)
assuming that there isn't a cost issue. It currently doesn't seem to
do this.
-- John
-------------------------------------------------------------------------
| Feith Systems | Voice: 1-215-646-8000 | Email: john@feith.com |
| John Wehle | Fax: 1-215-540-5495 | |
-------------------------------------------------------------------------
More information about the Gcc-patches
mailing list