It is not safe to forward loads and stores around if calls to setjmp are
present: there might be a call which longjmps causing a memory location
to be initialized with an unexpected value.
This fixes PR27848.
Differential D20555
[MemCpyOpt] Be conservative in the face of returns_twice calls majnemer on May 23 2016, 9:17 PM. Authored by
Details It is not safe to forward loads and stores around if calls to setjmp are This fixes PR27848.
Diff Detail
Event Timeline
Comment Actions I think the right fix is declare that volatile loads and stores "capture" their pointer operands, or to tease out some other function attribute like that. Your reduced test case from IRC shows how we incorrectly redirect volatile stores from y to x: https://ghostbin.com/paste/v5n3f Comment Actions lgtm, but let's bug Sanjoy, the person who seems to think the hardest about IPO function attrs right now. Comment Actions I'm fine being bugged, but I think this review is missing some context -- how is "volatile stores escape the location being stored to" related to how we handle setjmp / longjmp? A explicit test case on why we need this new rule will also be helpful (if not as a test case, then an example in the commit message), since @test_volatile only checks that we implement the rule correctly, but does not explain what the motivation is. Comment Actions We substituted the underlying storage for a pointer when calling some function, that function would later perform a volatile store to that pointer. This is important because setjmp and longjmp require any modifications to objects which are loaded after the longjmp to be performed with volatile accesses. This all falls apart if the wrong underlying object is stored to.
|