RE: [REVISED][PATCH/RFT] Fix PR middle-end/PR28690, modify swap_commutative_operands_p

["Dave Korn" <dave dot korn at artimi dot com>]

On 12 June 2007 18:09, Peter Bergner wrote:

> On Tue, 2007-06-12 at 18:50 +0200, Rask Ingemann Lambertsen wrote:
>> On Tue, Jun 12, 2007 at 10:46:48AM -0500, Peter Bergner wrote:
>> 
>>>   2) It seems like we could do better than the all or nothing alignment
>>>      .p2align gives us.  Obviously, we can't change the behavior of
>>>      .p2align, but it would have been nice (maybe a different/new
>>>      alignment macro?) if instead of giving up completely, it would have
>>>      increased the alignment as much as it could up to the requested 16
>>>      bytes within the 7 byte skip maximum.  So for example, if we
>>>      currently have 2 byte alignment and we ask for 16 byte alignment,
>>>      wouldn't it be nice if it gave us 8 byte alignment (which is within
>>>      7 bytes) rather than giving up completely?
>> 
>>    That would be '.p2align 3', wouldn't it?
> 
> I'm talking about .p2align's behavior and not the args to pass to it.
> Currently, you either get the alignment you ask for within the limits
> you specify, or you get nothing.  So ".p2align 4,,7" will give you
> 16 byte alignment or it won't change it at all.  All I'm saying, is
> if it can't give me 16 byte alignment because we'd have to skip more
> than 7 bytes, why can't it give me 8 byte alignment instead?  ...or
> 4 byte alignment?  ...or whatever is more aligned than my current
> alignment but still within the maximum byte skip value I specified?

  So instead of writing

    .p2align 4,,7

can't you write the sequence:

    .p2align 4,,7
    .p2align 3,,7

which will have the exact effect you're asking for there?

    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....