[PATCH] Fix for CodeGenPrepare wrongly updating the map of sunk addresses

Anton Korobeynikov anton at korobeynikov.info
Wed Apr 24 04:13:28 PDT 2013


Hi Andrea,

Are you sure the tests will pass on *every* x86 target? Regardless of
the platform?

On Wed, Apr 24, 2013 at 2:28 PM,  <Andrea_DiBiagio at sn.scee.net> wrote:
> Ping.
>
> (I am attaching a refreshed patch against r180180)
>
> (See attached file: patch-codegen-prepare.diff)
>
> Thanks!
> --Andrea DiBiagio
>
>
> Andrea DiBiagio/SN R&D/BS/UK/SCEE wrote on 19/04/2013 15:41:07:
>
>> Friendly ping.
>>
>> -- Andrea Di Biagio
>
>>
>> Andrea DiBiagio/SN R&D/BS/UK/SCEE wrote on 12/04/2013 18:56:08:
>>
>> > Hello,
>> >
>> > I'd like to contribute a patch to fix a problem in Pass CodeGen
> Prepare.
>> >
>> > Method OptimizeMemoryInst is not always able to correctly update
> DenseMap
>> > SunkAddrs by erasing no longer valid keys associated to Values which
> have
>> > been deleted in memory.
>> >
>> > When method OptimizeMemoryInst calls function
>> > `RecursivelyDeleteTriviallyDeadInstructions', potentially not all the
>> > dead keys are erased from the map SunkAddrs.
>> > Therefore, there are cases where map SunkAddrs is left in a
> inconsistent
>> > state where buckets associated to keys of deleted Values are
>> > still considered to be valid.
>> >
>> > This can be problematic for example in the following scenario where:
>> > 1. A new Instruction I created to replace the address expression for a
>> >    load or store instruction;
>> > 2. address of I is the same as a previously deleted Value
>> >    pointed to by a key K of map SunkAddrs;
>> > 3. K is still a valid key in SunkAddrs.
>> >
>> > CodeGenPrepare may think that occurrence of address I could be replaced
>> > with the Value returned by SunkAddrs[I] which is however invalid.
>> >
>> > PROPOSED FIX
>> > ------------
>> > With this patch, CodeGenPrepare now uses a CallbackVH as the key of
>> > map SunkAddrs. Each CallbackVH is able to monitor changes in the
>> > state of a specific key Value. When a key is deleted by
>> > method RecursivelyDeleteTriviallyDeadInstructions its associated
>> > CallbackVH is notified and the corresponding entry in SunkAddrs
>> > is correctly erased.
>> > I also added an x86 specific test case that exposes the problem
>> > found in CodeGenPrepare.
>> >
>> > Thanks!
>> > -- Andrea Di Biagio
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>



-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University



More information about the llvm-commits mailing list