[PATCH] D11969: Avoid using of DataLayout::getPointerSize() without address space argument in DWARF info generation

[Stanislav Mekhanoshin via llvm-commits]

rampitec added a comment.

In http://reviews.llvm.org/D11969#222468, @joker.eph wrote:

> Thanks for the details. I think I get this, let me ask a more specific question. What I don't understand right now is how MAI->getPointerSize() get the right size since it does not get an address space either?
>  It seems to me that any place that is using a single "getPointerSize()" would have the address space problem.
>  From what I see, MAI is created by the TargetMachine, that itself gets it from the Subtarget, using a Target specific factory function. So in the end it is just a struct initialized by the Target.
>  At this point I'm not even sure why MAI has a pointer size in the first place, I'm missing a piece of the puzzle or it does not seem right.


Well, for most applications the DataLayout method with a specific address space shall be used. Though there are some rare instances where pointer size is needed with no pointer available. Like in the debug info where you have to generally specify target bitness, or if you generally need to know a biggest data type to hold any pointer. That is how MAI version of this function works, without a specific pointer or data type. In the debug code where this is used no pointer is actually available, but that is fine to support debugging.

Then MAI can be specialized by the target, but so the AsmPrinter and TargetMachine. One difference is that MAI has data field PointerSize which is initialized by the target. Then getPointerSize simply returns this value. It does not hurt to refer to it with a base class pointer. What is currently in AsmPrinter and TargetMachine can be reimplemented by the target as well, but that does not help when dwarf support code calls it through a base class. There must be a data field specified by target, either variable or virtual function pointer. I suppose that is undesirable to virtualize common classes from the performance perspective, thus MAI implementation is handy here.


Repository:
  rL LLVM

http://reviews.llvm.org/D11969