This is the mail archive of the
mailing list for the GCC project.
Re: Volatile Memory accesses in Branch Delay Slots
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Jakob Wenzel <wenzel at rs dot tu-darmstadt dot de>, gcc at gcc dot gnu dot org
- Date: Tue, 25 Jul 2017 21:32:59 +0900
- Subject: Re: Volatile Memory accesses in Branch Delay Slots
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com>
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.