This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 11/22/13 18:43, Kai Tietz wrote:
Right, my point is the test didn't actually check for normalization, it just checks if there's a particular number/type of casts.So at least for f1 and f2, these regexps match regardless of whether or not the code was transformed. Without your patch (f1) x1_2 = (unsigned char) x_1(D); _3 = x1_2 << 5; return _3; With your patch (f1): _4 = x_1(D) << 5; _2 = (unsigned char) _4; return _2; So all that's happened is we changed which object got casted -- we have the same number casts of an object to (unsigned char).That is actual wished. We shouldn't come to patterns, which have more type-casts by this patch. What we see here is the normalization of shift-left/right operations. This patch takes care that we prefer in general (Type) (X shift-left/right y) over ((Type) X) shift-left/right y notation.
I think it's also worth pointing out for the record this patch in and of itself really isn't an optimization. It's setting a preferred form for shifts. I won't call it canonicalization because we don't insist on the this form, but it's the form we want to see.
Since it's just setting a preferred form and not an optimization, it seems to me we should expect it to sometimes generate better code and sometimes worse.
I'll take a closer look after I fix my arm regression :-) jeff
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |