[PATCH] fix for PR16393: miscompile with struct byval

Stepan Dyatkovskiy stpworld at narod.ru
Thu Jul 4 12:23:46 PDT 2013


Hi Manman,

> Have you tried other solutions?
Yes. I've tried several concepts, though some them seems to be ugly:
1. Try to mark somehow call-sequence-start BB, call-sequence-end-BB and call BB. Since (as we can see) in general it could be several basic blocks. In combination with your patch this approach gave me patch I presented in previous mail.

2. While scanning BBs in PEI::replaceFrameIndices, try to recognize copy loop. We know that original BB was expanded onto: head, loop and exit BBs, and we can treat with them as with single BB. It wasn't a good idea to do it straght in replaceFrameIndices, so ideally it should be one more backend hook method: something like getCallBBs()

3. Do the parameter copy *before* ADJSTACKDOWN node:
  COPY_STRUCT_BY_VAL -> ADJSTACKDOWN -> CALL -> ADJSTACKUP

> I am not so sure whether it works when we have transformations on MBB.
If any further tranformations are supposed, I think, we just should also update MBB clone implementation.

-Stepan.

03.07.2013, 23:15, "Manman Ren" <mren at apple.com>:
> On Jul 3, 2013, at 9:05 AM, Stepan Dyatkovskiy wrote:
>
>>  Hi Manman,
>>
>>  After some learning what exactly happens. IMHO, your decision is the *only* way (that couldn't be called too hackish or insane :-)).
>
> Have you tried other solutions?
>
>>  Though, may be we add SpAdj just as property for MachineBasicBlock class?
>
> Compared to using a pseudo SET_SP_ADJ, adding SPAdj as a property for MBB at least solves the issue of making sure SPAdj is available at the
> beginning of a basic block.
>
> I am not so sure whether it works when we have transformations on MBB.
> We also need to reset SPAdj when we try to eliminate call frame pseudo instructions in calculateCallsInformation.
>
> Thanks,
> Manman
>
>>  I've modified your patch, please find it in attachment.
>>
>>  -Stepan.
>>
>>  Manman Ren wrote:
>>>  For a call site with struct byval, we will generate a sequence of instructions: STACKDOWN, STRUCT_BYVAL and STACKUP.
>>>  STRUCT_BYVAL later on is expanded to a for loop. This caused issue in PEI when trying to eliminate frame indices.
>>>
>>>  BB1:
>>>    STACKDOWN
>>>  BB2:
>>>    memcpy
>>>  BB3:
>>>    STACKUP
>>>
>>>  PEI currently assumes SPAdj is 0 at the beginning of a basic block, but this is not true for BB2 or BB3. The proposed patch tries
>>>  to fix the problem by inserting SET_SP_ADJ in BB2 and BB3:
>>>  BB1:
>>>    STACKDOWN
>>>  BB2:
>>>    SET_SP_ADJ
>>>    memcpy
>>>  BB3:
>>>    SET_SP_ADJ
>>>    STACKUP
>>>
>>>  A target-independent opcode SET_SP_ADJ is introduced, and pseudo instruction STRUCT_BYVAL is modified to take one extra
>>>  argument (the amount of SP Adjustment). When we are expanding STRUCT_BYVAL to a for loop, we add SET_SP_ADJ to BB2 and BB3.
>>>
>>>  PEI is also modified to handle SET_SP_ADJ. To make sure SET_SP_ADJ is always before any spill code that references frame indices,
>>>  SET_SP_ADJ is treated as a label.
>>>
>>>  SET_SP_ADJ can be useful for other targets when STACKDOWN and STACKUP are not paired up in the same basic block.
>>>
>>>  Comments and other suggestions are welcome.
>>>
>>>  Thanks,
>>>  Manman
>>  <2013-06-03-byval-spadj.patch>



More information about the llvm-commits mailing list