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

Andrea_DiBiagio at sn.scee.net Andrea_DiBiagio at sn.scee.net
Wed Apr 24 03:28:19 PDT 2013


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-codegen-prepare.diff
Type: application/octet-stream
Size: 5316 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130424/35896be6/attachment.obj>


More information about the llvm-commits mailing list