[llvm-dev] My own codegen is 2.5x slower than llc?

David Jones via llvm-dev llvm-dev at lists.llvm.org
Tue May 29 05:30:42 PDT 2018


I don't. Unfortunately, I must compile the code I am given.

I do actually have mitigations in some places that break up long basic
blocks, but they are not universally applicable.  Interestingly, 14000
doesn't seem that big to me.  One of my mitigations was put in to break up
blocks with 2 million instructions.

If you generate a SystemVerilog UVM register model for a large SOC and it
has 70K registers in it, then your build() method will have 2 million
instructions in it.  That is the type of code I am given.


On Tue, May 29, 2018 at 8:15 AM, Bruce Hoult <brucehoult at sifive.com> wrote:

> What percentage of performance advantage do you expect to get from having
> a basic block with 14000 instructions, rather than breaking it up a bit?
>
> On Wed, May 30, 2018 at 12:02 AM, David Jones via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> My back-end code generator uses LLVM 5.0.1 to optimize and generate code
>> for x86_64.
>>
>> If I run it on a given sample of IR, it takes almost 5 minutes to
>> generate object code.  95%+ of this time is spent in
>> MergeConsecutiveStores().  (One function has a basic block with 14000
>> instructions, which is a pathological case for MergeConsecutiveStores.)
>>
>> If, instead, I dump out the LLVM IR, and manually run both opt and llc on
>> it with -O2, the whole affair takes only 2 minutes.
>>
>> I am using a dynamically linked LLVM library.  I have verified using GDB
>> that both my code generator and llc are invoking the shared library (i.e.
>> the exact same code) so I would not expect to see a 2.5x performance
>> difference.
>>
>> What could explain this?
>>
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180529/07eab3f9/attachment.html>


More information about the llvm-dev mailing list