------- Additional Comments From roger at eyesopen dot com 2004-11-09 20:56 ------- I agree with Stuart :>
Although both of the patches he investigated will cure the problem, reverting mine will generate a movzbl, whilst disabling the TARGET_PARTIAL_... bits will generate a "movb". As hinted in the original problem description, when optimizing for size we ideally want the smaller "movb" (2 bytes vs. 3 bytes). But I still don't think disabling the TARGET_PARTIAL_... bits completely is an ideal solution. It would be better to take advantage of any alignment information on the MEM to determine whether this transformation is safe, and still benefit from this optimization when it is. I'm also still not convinced that there aren't any non -Os cases where the existing TARGET_PARTIAL_... code is incorrect without checking alignment. Perhaps initially we should disable TARGET_PARTIAL_... only when optimizing for size? I'm not convinced its perfect, but it would resolve this failure and not hurt performance at -O2/-O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
