[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