[llvm] r281289 - [lib/LTO] Expose getModule() in lto::InputFile.

Mehdi Amini via llvm-commits llvm-commits at lists.llvm.org
Mon Sep 12 20:05:16 PDT 2016


Sneaky ping on https://reviews.llvm.org/D23132 :)

(In the meantime: +1 to Peter, please revert)

-- 
Mehdi
Sent from my iPhone

> On Sep 12, 2016, at 7:56 PM, Davide Italiano <davide at freebsd.org> wrote:
> 
>> On Mon, Sep 12, 2016 at 7:49 PM, Peter Collingbourne <peter at pcc.me.uk> wrote:
>> We shouldn't expose the module here because we will eventually want this
>> class to wrap the bitcode symbol table rather than the module.
>> 
>> Is there something more minimal you can expose here to achieve the same
>> goal?
>> 
> 
> The intent here is to replace this code:
> 
> void BitcodeCompiler::add(BitcodeFile &F) {
>  std::unique_ptr<IRObjectFile> Obj = std::move(F.Obj);
>  std::vector<GlobalValue *> Keep;
>  unsigned BodyIndex = 0;
>  ArrayRef<Symbol *> Syms = F.getSymbols();
> 
>  Module &M = Obj->getModule();
>  if (M.getDataLayoutStr().empty())
>    fatal("invalid bitcode file: " + F.getName() + " has no datalayout");
> 
> 
> Is there a way to get the data layout without accessing the module?
> Otherwise lld fails without emitting a diagnostic, which is not ideal.
> 
> If you don't want this to be exposed, I can move the logic to libLTO
> itself, i.e. inside LTO::add() but I'm not quite sure how that will
> affect the other clients.
> 
> Thanks,
> 
> --
> Davide
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160912/379f91b9/attachment.html>


More information about the llvm-commits mailing list