[PATCH] Handling of aligned allocas / stack alignment

[Jonas Paulsson via llvm-commits]

On 2015-10-23 19:00, Hal Finkel wrote:
> ----- Original Message -----
>> From: "Jonas Paulsson via llvm-commits" <llvm-commits at lists.llvm.org>
>> To: llvm-commits at lists.llvm.org
>> Sent: Friday, October 23, 2015 11:50:44 AM
>> Subject: [PATCH] Handling of aligned allocas / stack alignment
>>
>> Hi,
>>
>> I have been working on a patch to implement dynamic realignment for a
>> target that does not align the stack pinter to any greater alignment
>> than the normal alignment (SystemZ).
>>
>> The patch changes the behaviour in FunctionLoweringInfo, so that for
>> a
>> target that has a non-realignable stack, greaterly-aligned static
>> allocas are considered to be variable-sized objects and are handled
>> with
>> a DYNAMIC_STACKALLOC node.
>>
>> I am not sure about the "no-realign-stack" Function attribute. Is
>> this
>> an attribute that is only relevant to targets that generally realign
>> the
>> stack? Or does it make any target required to drop all alignments of
>> allocas? I would appreciate any comments and opinions on this.
>> (Depending on what is the correct approach, this also affects when
>> warnings should be printed for dropped alignments, as can be seen in
>> this non-final patch).
> My understanding is that 'no-realign-stack' is a promise that the user is providing to the backend that the incoming stack alignment is really much larger than the ABI generally requires, at least large enough to handle any overaligned allocas that might be present, and so realignment will never be necessary.
>
>   -Hal
I see. I guess then it makes sense to skip alignments generally in that 
case.

Does anybody else have any comments on this patch? What should it mean 
when TargetFrameLowering->isStackRealignable() returns false? This patch 
suggests that this target would handle any alignment request 
dynamically, and so puts also overaligned static allocas for handling by 
a DYNAMIC_STACKALLOC node. I realize that no in-tree target does this,
so if there are no objections, I will assume that this is ok for now at 
least.

/Jonas
>
>> (resending a somewhat updated patch)
>>
>> /Jonas Paulsson
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>