On Fri, Jul 22, 2011 at 2:07 PM, Andrew Stubbs <a...@codesourcery.com> wrote: > ENOPATCH .... > > On 22/07/11 12:57, Andrew Stubbs wrote: >> >> On 21/07/11 14:22, Richard Guenther wrote: >>> >>> On Thu, Jul 21, 2011 at 2:53 PM, Andrew Stubbs<a...@codesourcery.com> >>> wrote: >>>> >>>> This patch is part bug fix, part better optimization. >>>> >>>> Firstly, my initial patch series introduced a bug that caused an >>>> internal >>>> compiler error when the input to a multiply was a constant. This was >>>> caused >>>> by the gimple verification rejecting such things. I'm not totally >>>> clear how >>>> this ever worked, but I've corrected it by inserting a temporary >>>> SSA_NAME >>>> between the constant and the multiply. >>> >>> Huh? Constant operands should be perfectly fine. What was the error >>> you got? >> >> Ok, so it seems that the fold_convert we thought was redundant in patch >> 5 (now moved to patch 2) was in fact responsible for making constants >> the right type. >> >> I've rewritten it to use fold_convert to change the constant. >> >>>> I also discovered that widening multiply-and-accumulate operations >>>> were not >>>> recognised if any one of the three inputs were a constant. I've >>>> corrected >>>> this by adjusting the pattern matching. This also required inserting new >>>> SSA_NAMEs to make it work. >>> >>> See above. >> >> The pattern matching stuff remains the same, but the constant >> conversions have been updated. >> >>>> In order to insert the new SSA_NAME, I've simply reused the existing >>>> type >>>> conversion code - the only difference is that the conversion may be a >>>> no-op, >>>> so it just generates a straight forward assignment. >>>> >>>> OK? >>> >>> Nope. I suppose you forget to adjust the constants type? Just >>> fold-convert it before using it as input to a macc. >> >> Done. >> >> OK?
Ok. Thanks, Richard. >> Andrew >> > >
