llvm dev - Jul 2011 - [LLVMdev] How to prevent generation of wide integers in LLVM IR?

On 01.07.2011 12:03, Eli Friedman wrote:
> On Fri, Jul 1, 2011 at 12:53 AM, Корчагин Василий
> <vasiliy.korchagin at gmail.com>  wrote:
>> Hello, LLVMdev.
>>
>> 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.
>
> -Eli
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.
You wrote that I can avoid emitting such code. Could you give me 
direction, where I can begin my hack?

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

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!