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

Stanislav Mekhanoshin via llvm-commits llvm-commits at lists.llvm.org
Wed Aug 12 19:59:55 PDT 2015


rampitec added a comment.

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

> Oh I thought you were talking about defining the result of getPointerSize() as being a "base pointer size" or something like that. Got what you meant now.
>
> I discussed with a few people around and my impression so far is that
>
> - The DataLayout does not defined anything about which address space the code resides in
> - The code for a single module can only be generated in one address space
> - Everything is fine as long as the DataLayout is specified using address space 0 for the code
> - MCAsmInfo::PointerSize is intended to describe the size of a pointer to the memory space where the code resides.
>
>   If this is correct, it seems to me that on the short term we should to solve your problem:
> - rename MCAsmInfo::PointerSize to something more explicit like MCAsmInfo::CodePointerSize
> - remove the hook AsmPrinter::getPointerSize() and redirect client to use explicitly MCAsmInfo::getCodePointerSize or DataLayout::getPointerSize
>
>   On a longer term, I wonder if this information shouldn't be part of the DataLayout as well. I'm not sure what the implication on the IR level optimizations can be at this point.
>
>   I hope this makes sense?


Yes, it makes a lot of sense for me. I will change it to the first solution if there are no objections.


Repository:
  rL LLVM

http://reviews.llvm.org/D11969





More information about the llvm-commits mailing list