[llvm-commits] [llvm] r167942 - /llvm/trunk/lib/Transforms/Vectorize/BBVectorize.cpp

[Hal Finkel]

----- Original Message -----
> From: "Chandler Carruth" <chandlerc at google.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: "Commit Messages and Patches for LLVM" <llvm-commits at cs.uiuc.edu>
> Sent: Wednesday, November 14, 2012 3:32:12 PM
> Subject: Re: [llvm-commits] [llvm] r167942 - /llvm/trunk/lib/Transforms/Vectorize/BBVectorize.cpp
> 
> On Wed, Nov 14, 2012 at 1:29 PM, Hal Finkel <hfinkel at anl.gov> wrote:
> > ----- Original Message -----
> >> From: "Chandler Carruth" <chandlerc at google.com>
> >> To: "Hal Finkel" <hfinkel at anl.gov>
> >> Cc: "Commit Messages and Patches for LLVM"
> >> <llvm-commits at cs.uiuc.edu>
> >> Sent: Wednesday, November 14, 2012 3:20:21 PM
> >> Subject: Re: [llvm-commits] [llvm] r167942 -
> >> /llvm/trunk/lib/Transforms/Vectorize/BBVectorize.cpp
> >>
> >> On Wed, Nov 14, 2012 at 10:38 AM, Hal Finkel <hfinkel at anl.gov>
> >> wrote:
> >> > Author: hfinkel
> >> > Date: Wed Nov 14 12:38:11 2012
> >> > New Revision: 167942
> >> >
> >> > URL: http://llvm.org/viewvc/llvm-project?rev=167942&view=rev
> >> > Log:
> >> > Fix the largest offender of determinism in BBVectorize
> >> >
> >> > Iterating over the children of each node in the potential
> >> > vectorization
> >> > plan must happen in a deterministic order (because it affects
> >> > which
> >> > children
> >> > are erased when two children conflict). There was no need for
> >> > this
> >> > data
> >> > structure to be a map in the first place, so replacing it with a
> >> > vector
> >> > is a small change.
> >> >
> >> > I believe that this was the last remaining instance if iterating
> >> > over the
> >> > elements of a Dense* container where the iteration order could
> >> > matter.
> >> > There are some remaining iterations over std::*map containers
> >> > where
> >> > the order
> >> > might matter, but so long as the Value* for instructions in a
> >> > block
> >> > increase
> >> > with the order of the instructions in the block (or decrease)
> >> > monotonically,
> >> > then this will appear to be deterministic.
> >>
> >> Pointers should not be assumed to be deterministically ordered.
> >> Any
> >> ordering which is based on the numerical sort of addresses is a
> >> non-determinism bug.
> >
> > Agreed. As I said to Sean just a few minutes ago:
> 
> Sorry, wasn't aware that replaced the Value* ordering issue. =] Sorry
> for the noise!
> 

No problem; nevertheless, I should replace the std::multimap with something else anyway, I just need to figure out what to use. I was using the multimap to avoid the copying costs that I'd get with some naive map-of-vectors or vector-of-vectors implementation.

 -Hal

-- 
Hal Finkel
Postdoctoral Appointee
Leadership Computing Facility
Argonne National Laboratory