[LLVMdev] How to prevent generation of wide integers in LLVM IR?

[Корчагин Василий]

01.07.2011 17:21, Frits van Bommel пишет:
> On 1 July 2011 13:35, Vasiliy Korchagin<vasiliy.korchagin at gmail.com>  wrote:
>> On 01.07.2011 12:03, Eli Friedman wrote:
>>> On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий
>>> <vasiliy.korchagin at gmail.com>    wrote:
>>>> The problem is that C backend doesn't support integers wider than 64
>>>> bits, but I need to use it on programs with wide integers in LLVM IR. My
>>>> question is how to deny LLVM to generate wide integer? Which part of
>>>> LLVM should I modify?
>>> scalarrepl is the only pass I can think of off the top of my head that
>>> does that normally (although there might be others); you can either
>>> avoid it (in favor of the simpler mem2reg), or hack it up so it
>>> doesn't do that.
>>>
>> scalarrepl didn't help. Command "opt -scalarrepl input.bc -o output.bc"
>> produced the same bitcode, there are no changes in file. Neither helped
>> scalarrepl-ssa.
>
> He meant that you should *avoid* scalarrepl. It's the pass that
> usually introduces such large integer types, and it's one of the
> default passes that runs when optimizations are run by the compiler or
> 'opt -O[1-3]/-std-compile-opts'.
>
>> You wrote that I can avoid emitting such code. Could you give me
>> direction, where I can begin my hack?
>
> It used to be that -O1 used -mem2reg instead of -scalarrepl, but I
> don't think that's the case anymore.
> If you want optimizations, you'll need to construct your own pass
> order, and make sure -scalarrepl isn't in it.
> You can look at the output of 'opt -debug-pass=Arguments ...' (or
> include/llvm/Support/PassManagerBuilder.h) to see what passes are
> normally used. If you're looking at the opt output, beware that some
> of those passes are analysis passes that get added automatically and
> shouldn't be added manually.
>
> To avoid -scalarrepl, just pretend it says -mem2reg instead of
> -scalarrepl (or createPromoteMemoryToRegisterPass() instead of
> createScalarReplAggregatesPass(...), if you're reading the header).
>
>
> Alternatively, you could volunteer to rewrite the C backend to use the
> common backend infrastructure used by most of the other backends (as
> has been proposed on this list before). That would enable it to handle
> wide integers: they would "automatically" get split into multiple
> smaller integers by the common infrastructure.
> This would probably be a pretty large undertaking though, so I suspect
> you'd be much better off by just defining your own pass order :).

Replacing scalarrepl with mem2reg helped me. Thanks a lot!