dense maps

Reading the LLVM Programmer’s Manual, the description of DenseSet mentions:

Note that DenseSet has the same requirements for the value type that DenseMap has.

But when I read about DenseMap, I don’t really see any requirements for the values, just a warning about space. On the other hand, the keys have special requirements, which aren’t entirely clear to me. It says

Finally, you must implement a partial specialization of DenseMapInfo for the key that you want, if it isn’t already supported. This is required to tell DenseMap about two special marker values (which can never be inserted into the map) that it needs internally.

Will my code fail to compile if the required specialization of DenseMapInfo is not present?

I wonder all these things because I’ve tripped across a problem where a method hangs repeatably, and I don’t see the problem.

typedef SmallVector<BasicBlock *, 4> Frontier;

DenseMap<BasicBlock , Frontier> frontier(blocks3/2);

BasicBlock *Xblock = …

errs() << “start\n”;

Frontier &f = frontier[Xblock]; // Xblock is not yet represented in frontier

errs() << “finish\n”;

It compiles fine (as part of a function-level pass), but the call frontier[Xblock] fails (hangs) after several successful calls. I tried replacing the declaration of frontier with

DenseMap<BasicBlock *, Frontier > frontier(blocks3/2);

but trip over the same problem in the same place.

I’ve used the DenseMap successfully in several other places, so I’m not sure that’s gone wrong here.

Any ideas?

Thanks,
Preston

Reading the LLVM Programmer’s Manual, the description of DenseSet mentions:

Note that DenseSet has the same requirements for the value type that DenseMap has.

But when I read about DenseMap, I don’t really see any requirements for the values, just a warning about space. On the other hand, the keys have special requirements, which aren’t entirely clear to me. It says

Finally, you must implement a partial specialization of DenseMapInfo for the key that you want, if it isn’t already supported. This is required to tell DenseMap about two special marker values (which can never be inserted into the map) that it needs internally.

Will my code fail to compile if the required specialization of DenseMapInfo is not present?’

It should fail to compile. Modifying DenseMapInfo.h to exclude the pointer and pair DenseMapInfo definitions causes compile failures.

I wonder all these things because I’ve tripped across a problem where a method hangs repeatably, and I don’t see the problem.

typedef SmallVector<BasicBlock *, 4> Frontier;

DenseMap<BasicBlock , Frontier> frontier(blocks3/2);

BasicBlock *Xblock = …

errs() << “start\n”;

Frontier &f = frontier[Xblock]; // Xblock is not yet represented in frontier

errs() << “finish\n”;

It compiles fine (as part of a function-level pass), but the call frontier[Xblock] fails (hangs) after several successful calls. I tried replacing the declaration of frontier with

DenseMap<BasicBlock *, Frontier > frontier(blocks3/2);

but trip over the same problem in the same place.

I’ve used the DenseMap successfully in several other places, so I’m not sure that’s gone wrong here.

Any ideas?

Does casting the BasicBlock* to uintptr_t and using a DenseMap of uintptr_t cause the same problem?

Cameron

Reading the LLVM Programmer’s Manual, the description of DenseSet mentions:

Note that DenseSet has the same requirements for the value type that DenseMap has.

But when I read about DenseMap, I don’t really see any requirements for the values, just a warning about space.

DenseSet is implemented as a DenseMap<T,char>, so requirements for DenseMap keys apply. It seems the documentation could be clearer.

If your elements are pointers, SmallPtrSet<> is a better choice.

Finally, you must implement a partial specialization of DenseMapInfo for the key that you want, if it isn’t already supported. This is required to tell DenseMap about two special marker values (which can never be inserted into the map) that it needs internally.

Will my code fail to compile if the required specialization of DenseMapInfo is not present?

Yes. The non-specialized DenseMapInfo template doesn’t provide any of the required methods.

I wonder all these things because I’ve tripped across a problem where a method hangs repeatably, and I don’t see the problem.

typedef SmallVector<BasicBlock *, 4> Frontier;

DenseMap<BasicBlock , Frontier> frontier(blocks3/2);

Pointer keys work fine, you don’t need to provide any specializations for that.

BasicBlock *Xblock = …

errs() << “start\n”;

Frontier &f = frontier[Xblock]; // Xblock is not yet represented in frontier

errs() << “finish\n”;

It compiles fine (as part of a function-level pass), but the call frontier[Xblock] fails (hangs) after several successful calls. I tried replacing the declaration of frontier with

DenseMap<BasicBlock *, Frontier > frontier(blocks3/2);

but trip over the same problem in the same place.

I’ve used the DenseMap successfully in several other places, so I’m not sure that’s gone wrong here.

Any ideas?

DenseMap iterators are invalidated by any container mutation. That is different behavior from std::map. Same thing for pointers and references to elements in the container. DenseMap invalidation works more like std::vector. It is not clear from your code if that is our problem.

I don’t recall seeing a DenseMap::operator hanging. Most likely, the backing memory was corrupted somehow.

/jakob

My problem was that the constructor for DenseMap has an undocumented constraint.

explicit DenseMap(unsigned NumInitBuckets = 0) {
init(NumInitBuckets);
}

if given an explicit argument, requires that the argument be a power of 2.

It’s checked by an assert in init(), but for some reason my code didn’t trip the assertion.
Is there a special way I must make to enable asserts?

Thanks,
Preston

My problem was that the constructor for DenseMap has an undocumented constraint.

explicit DenseMap(unsigned NumInitBuckets = 0) {
init(NumInitBuckets);
}

if given an explicit argument, requires that the argument be a power of 2.

It’s checked by an assert in init(), but for some reason my code didn’t trip the assertion.
Is there a special way I must make to enable asserts?

Hi Preston,

Add “–enable-assertions=yes” on your configure line if you’re using configure/make. Personally, I also use “–enable-optimized=no” for my development builds.

Regards,
Jim

IIRC, assertions are enabled by default if you’re building from SVN, and disabled by default if you’re building from a release tarball.

–Owen