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

Frits van Bommel fvbommel at gmail.com
Fri Jul 1 06:21:50 PDT 2011

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 :).

More information about the llvm-dev mailing list