This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Need advice on bounds checking approaches


Greg McGary <gkm@eng.ascend.com> writes:

> Is there some other advantage to memory-barrier semantics wrt. bounds
> checks that I'm overlooking?

I just thought of one: in a flat-memory-model system (say an embedded
system), it might useful to have a policy whereby a task is terminated
immediately upon detection of a bounds violation, and it's desirable
to terminate it before it has a chance to scribble on some other
task's memory.  OTOH, this is tricky business: you need some means of
releasing resources locked by the newly terminated task and rolling
back any partially completed work.  It sounds like a ton of work to
implement correctly, so the benefit of memory-barrier semantics is not
easily realized.

Does anyone know what optimizations barrier semantics will inhibit?
Instruction scheduling and code motion in the loop optimizer are the
two that spring to mind.

Greg

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]