llvm dev - Oct 2017 - Stack pointer updates and hoisting/scheduling vs interrupts

Hi llvm-dev,

On a number of occations we've run into different versions of problems 
with our out-of-tree target when it comes to scheduling of stack pointer 
updates vs interrupts at unfortunate places.

Example:

If we allocate an object on the stack with alignment we get something like:

mv sp, r0
sub r0, 2, r0
and r0, 0xfffe, r0
mv r0, sp

and then there might follow an instruction storing to the allocated space:

store 42, r0

and further down a load from it

load r0, r1

The problem we've run into is that the store is scheduled before the 
update of sp:

mv sp, r0
sub r0, 2, r0
and r0, 0xfffe, r0
store 42, r0
mv r0, sp

This works well in most cases, but if we are unfortunate enough to 
trigger an interrupt after the store, but before the sp update, the 
interrupt code might overwrite the stuff that the store just wrote to 
the stack, so when we continue after the interrupt, the last load might 
read rubbish data.

The store is only depending on r0, but we would like to make sure that 
the actual move to sp is carried out before it too.

I've failed to see how other targets solve this kind of problem, I 
suppose we're not alone in facing this issue?

Regards,
Mikael

Can't really help here, but it does sound wrong, and something that the
compiler should be able to "deal with" (that "this is a stack
adjustment,
and it needs to be done atomically before stack is used"). I've run
into
similar bugs in the past, where some [not clang+llvm] compiler doesn't
understand that the stack pointer is not "only used by this function".

--
Mats

On 16 October 2017 at 12:08, Mikael Holmén via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi llvm-dev,
>
> On a number of occations we've run into different versions of problems
> with our out-of-tree target when it comes to scheduling of stack pointer
> updates vs interrupts at unfortunate places.
>
> Example:
>
> If we allocate an object on the stack with alignment we get something like:
>
> mv sp, r0
> sub r0, 2, r0
> and r0, 0xfffe, r0
> mv r0, sp
>
> and then there might follow an instruction storing to the allocated space:
>
> store 42, r0
>
> and further down a load from it
>
> load r0, r1
>
> The problem we've run into is that the store is scheduled before the
> update of sp:
>
> mv sp, r0
> sub r0, 2, r0
> and r0, 0xfffe, r0
> store 42, r0
> mv r0, sp
>
> This works well in most cases, but if we are unfortunate enough to trigger
> an interrupt after the store, but before the sp update, the interrupt code
> might overwrite the stuff that the store just wrote to the stack, so when
> we continue after the interrupt, the last load might read rubbish data.
>
> The store is only depending on r0, but we would like to make sure that the
> actual move to sp is carried out before it too.
>
> I've failed to see how other targets solve this kind of problem, I
suppose
> we're not alone in facing this issue?
>
> Regards,
> Mikael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171016/f51d5efa/attachment.html>