[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Volatile Memory accesses in Branch Delay Slots
From:       Jeff Law <law () redhat ! com>
Date:       2017-07-25 15:40:31
Message-ID: d7787b3f-9450-5642-ffac-21cf36176073 () redhat ! com
[Download RAW message or body]

On 07/25/2017 06:32 AM, Oleg Endo wrote:
> On Tue, 2017-07-25 at 10:47 +0200, Jakob Wenzel wrote:
>>  
>> jr's delay slot is not filled. However, if the declaration of a is 
>> changed to `extern int a`, the delay slot is filled with the sw.
>>
>> The function responsible for this behavior seems to be 
>> resource_conflicts_p in reorg.c. Sadly, I could not find any
>> comments 
>> explaining why volatile accesses cannot be put into delay slots.
>>
>> What is the reason for this behavior? I am unable to think of any 
>> situation where allowing volatile memory accesses in branch delay
>> slots  leads to problems. Am I missing a case? Or are negative
>> effects limited  to other architectures?
> 
> Maybe because the code that does the delay slot stuffing does not do
> sophisticated checks whether such instruction reordering would not
> violate anything?  So it's playing safe and bails out if it sees
> "volatile mem".  Same thing happens also with insns that have multiple
> sets.  Ideally it should do some more fine grained checks and give the
> backend an option to opt-in or opt-out.
Essentially, the mantra has always been "be very conservative with
volatile objects" -- in the context of reorg that means little/no effort
is expended in trying to use a volatile memory access to fill a delay slot.

A volatile memory reference in a nullified delay slot may not do the
expected thing, depending on when/how nullification occurs within the
processor.   More generally, all of the speculative delay slot fillers
would be a concern if volatile accesses were allowed in delay slots.

I could speculate that fill_simple_delay_slots could probably safely be
improved to utilize instructions with volatile memory operands to fill
slots.  But it hardly seems worth the effort given the directions in
processor design/implementation over the last 20+ years.


Jeff
[prev in list] [next in list] [prev in thread] [next in thread]