Need help with bugpoint for codegen problem

This means that one of the passes in gccas or gccld is mis-optimizing
the code, since the unoptimized code works. See the "debugging gccas"
and "debugging gccld" sections of the "How To Submit a Bug" document:

Nope, that's not built into bugpoint, hence the procedures in the

You need a space between -instcombine and -load-vn, they are separate

Misha Brukman wrote:
>>bugpoint: Unknown command line argument '-instcombine-load-vn'. Try:
>>'bugpoint --help'
>You need a space between -instcombine and -load-vn, they are separate

Thanks. I've finally added all passes from gccas and gccld, giving me:


*** Optimized program matches reference output! No problem detected...
bugpoint can't help you with your problem!

I know it's a stretch, but have you tried *just* the gccas passes,
without gccld? Failing that, please send me (off-list) the
(unoptimized) bytecode file that runs and I'll see what I can do.

Also, please specify your architecture and OS.

I've finally got it working! The key point was to pass all bytecode
objects individually to bugpoint, and not to use the pre-linked bytecode from gccld.


After running for some time bugpoints exits saying:

*** The following functions are being miscompiled: ucl_alloc main
l3_ucl_alloc_endif_2E_i l1_ucl_alloc_UnifiedReturnBlock_2E_i
l1_ucl_alloc_UnifiedReturnBlock l1_main_shortcirc_next_2E_6_2E_i
Outputting reduced bytecode files which expose the problem:
  Non-optimized portion: Emitted bytecode to 'bugpoint-tonotoptimize.bc'
  Portion that is input to optimizer: Emitted bytecode to

*** You can reproduce the problem with: opt bugpoint-tooptimize.bc
-globalsmodref-aa -load-vn -gcse

Entered as bug 555 - . I hope someone can figure out the actual problem from the bytecode files.

Fixed, thanks a lot. Bugpoint gave me exactly what I needed to know, which is saying a lot considering that it was an interprocedural analysis that was mucking up. :slight_smile:


Uhm, that's bad. Would it be possible to add it as a test program in our llvm-test suite?


That's definitely good, but it seems like UCL is very good at exposing bugs in LLVM. :slight_smile: To avoid this happening in the future, could you put together a simple test (like you are using to check for correctness) that we can use to test the compiler?

As a bonus, this will also be used for performance tracking, so LLVM would be more likely to compile your code to a faster result if its in our testsuite. :slight_smile:

To add it to our suite, I basically need the following:

1. All of the source files in one directory
2. A list of compiler flags to build with
3. Any input files
4. Instructions on how to run the program.

We're always looking for new interesting test cases :slight_smile: