This is the mail archive of the
mailing list for the GCC project.
Re: Volatile Memory accesses in Branch Delay Slots
- From: Jeff Law <law at redhat dot com>
- To: Oleg Endo <oleg dot endo at t-online dot de>, Jakob Wenzel <wenzel at rs dot tu-darmstadt dot de>, gcc at gcc dot gnu dot org
- Date: Tue, 25 Jul 2017 09:40:31 -0600
- Subject: Re: Volatile Memory accesses in Branch Delay Slots
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 8BD10267D7
- References: <firstname.lastname@example.org> <email@example.com>
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
>> 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.