search for: nospecul

..., making this semantic undesirable. Related problems arise in loop unswitching as well. The proposed change is to split the semantics of convergent into two annotations: convergent - this operation may not be made control dependent on any additional values (aka may not be sunk into a condition) nospeculate - this operation may not be added to any program trace on which it was not previously executed (same as notrap?) Most of today’s convergent operations (barriers, arithmetic gradients) would continue to be marked only as convergent. The new semantics would allow full loop unrolling, and provide...

----- Original Message ----- > From: "Andrew Trick" <atrick at apple.com> > To: "Sanjoy Das" <sanjoy at playingwithpointers.com> > Cc: "Daniel Berlin" <dberlin at dberlin.org>, "llvm-dev" <llvm-dev at lists.llvm.org>, "Joseph Tremoulet" > <jotrem at microsoft.com>, "Oscar Blumberg"

.... Related problems arise in loop unswitching as well. > > The proposed change is to split the semantics of convergent into two annotations: > convergent - this operation may not be made control dependent on any additional values (aka may not be sunk into a condition) > nospeculate - this operation may not be added to any program trace on which it was not previously executed (same as notrap?) > > Most of today’s convergent operations (barriers, arithmetic gradients) would continue to be marked only as convergent. The new semantics would allow full loop unrolling, a...

...be made control dependent on any additional values (aka may not be sunk into a condition) > To be clear, this is a restriction of current semantics only right? That depends on what you mean by restriction. It allow strictly more code motion than is allowed by the current semantics. >> nospeculate - this operation may not be added to any program trace on which it was not previously executed (same as notrap?) > Isn't this already true of all instructions? Unless we can *prove* that speculating an instruction can't introduce faults, we can't speculate it ever. An unknown ca...

...ing changes: > > - Add a "gc" address space to the datalayout string > I don't really understand the need for this yet, because the following point: > - Start implementing the non-controversial rules (i.e. everything > except the bits that initiated the "nospeculate" attribute > discussion): > I think everything here should apply to *all* non-zero address spaces. I think the thing we would want is for a tagged address space to opt *out* of this conservative behavior, not the other way around. So I don't think you need a tagged address s...