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
