I've been following the discussion a bit about contributing, and find
myself here now even directly pointed at :-) As I mentioned, I am not very
experienced with GCC, for one thing I have not studied other ports very
much. To make a GCC patch for this problem to be generally handled is then
a bit over my head, but perhaps with some mentoring from someone with
enough experience, I could give it a try!
Problem: even if a widening pattern is defined in the .md-file, it may not
end up being used, as it should per definition if it is prior to other
mul-patterns in the file. If it is located afterwards, then it may be a
matter of discussion, if one would not like to consider these preferable.
The solution of handling this during expansion that I used, is not wrong
the way I see it. Since more than one Gimple pass is involved in this
problem - rewriting the code so that the RTL-expander will use a wide
mult-insn - it seems quite logical to simply undo this during expansion in
terms of reactivating the original operands. Much simpler to have this fix
in one place, as it is a bit of a side issue, I think.
I would like to see that all widening mult-patterns defined prior to wide
mult-patterns in the .md file, end up being used when feasable - this is
logical.
An extended solution to what I used could perhaps do this work prior to
emitting wide mult-insns:
1. initialization: generate extension RTL, so that the extending insns
(lists) can be recognized on each target.
2. prior to expanding a multiplication:
if widening mult-pattern that suits the mode is defined
try to find both operands origins of extension per point 1.
if both operands extended:
emit widening pattern
else
emit wide pattern
I am not certain this is a complete solution, it is merely my immediate
thoughts, so please correct me. If somebody believes in correcting this
GCC behaviour and have the time to guide me, I would be happy to
participate.
/Jonas
>> From: "Jonas Paulsson" <d0...@student.lth.se>
>> Date: Mon, 26 Apr 2010 11:07:04 +0200
>
>> I recently completed my degree project on LTH on retargeting GCC. See
>> http://sam.cs.lth.se/ExjobGetFile?id=224 for my report (it will be moved
>> to
>> http://cs.lth.se/examensarbete/rapporter/rapporter_2010/ soon).
>
> Interesting observations there; I wish there was incentive for
> you to actually resolve them the right way in GCC, meaning this
> project.
>
> I've recently been bitten by the lost-widening-multiplication-
> when-in-loop issue myself, and noted it for revisit Some Day.
> Fixing that by other means made a whopping 27% improvement for
> the application where I saw it: a hot loop doing a MDCT using
> Q31 fixed-point, where a common operation is to widen-multiply
> two 32-bit numbers and pick the high 32 bits of the 64-bit
> result (being the result divided by 2; i.e. Q30-ish for that
> operation).
>
> brgds, H-P
>
