OpenCores
Issue List
Toolchain Optimization #156
Closed tsuckow opened this issue almost 13 years ago
tsuckow commented almost 13 years ago

The or32 toolchain appears to be incapable of even simple optimizations.

Below is a sample from a simple loop that writes a value to consecutive words in memory.

This is what the or32 toolchain from git generated with -O3:

22f8: 18 40 ff ff l.movhi r2,0xffff //constant i is checked against 22fc: d4 03 20 00 l.sw 0x0(r3),r4 //Store value to memory 2300: a8 42 0a f0 l.ori r2,r2,0xaf0 //constant i is checked against 2304: 9c 63 ff fc l.addi r3,r3,0xfffffffc //--i 2308: e4 23 10 00 l.sfne r3,r2 //check i 230c: 13 ff ff fb l.bf 22f8

This is what I would expect to be generated (note the branch target change):

22f8: 18 40 ff ff l.movhi r2,0xffff //constant i is checked against 22fc: a8 42 0a f0 l.ori r2,r2,0xaf0 //constant i is checked against 2230: d4 03 20 00 l.sw 0x0(r3),r4 //Store value to memory 2304: 9c 63 ff fc l.addi r3,r3,0xfffffffc //--i 2308: e4 23 10 00 l.sfne r3,r2 //check i 230c: 13 ff ff fb l.bf 2230

jeremybennett commented almost 13 years ago
<p> The definitive tool chain is on SVN. Currently tagged as 4.5.1-or32-1.0rc4. You have presumably picked up a mirror somewhere. Are you up to date? </p> <p> Could you post the source code and the compiler line that you used to generate the code. Without this it is impossible to assess this error. </p> <p> Jeremy </p> <p> -- <br /> Tel: +44 (1590) 610184<br /> Cell: +44 (7970) 676050<br /> SkypeID: jeremybennett<br /> Email: <a href="mailto:jeremy.bennett@embecosm.com">jeremy.bennett@embecosm.com</a><br /> Web: <a href="http://www.embecosm.com">www.embecosm.com</a> </p>
jeremybennett was assigned almost 13 years ago
tsuckow commented almost 13 years ago

I am using rc1 from: http://git.openrisc.net/cgit.cgi/jonas/toolchain/

I will update my toolchain and get back to you.

Regardless, here is a simplified build showing the issue: http://www.wuala.com/Deathbob/Files/OR32/Toolchain_LoopBug.zip

jeremybennett commented almost 13 years ago
<p> Hi Thomas, </p> <p> Thanks for the example - I understand what is going wrong here. </p> <p> Many GCC optimizations rely on an accurate model of the processor pipeline to determine the best code sequence. At present the OpenRISC 1000 compiler does not have an accurate pipeline model, and in particular loading constants appears to take zero cycles. Hence the constant load is not hoisted out of the loop. The code will always be correct, but not necessarily as fast as possible. </p> <p> This will be fixed in time. However the priority to date has been to get robust code generation. Although C and C++ support is now generally good, there are still a number of errors in the C++ library that must be fixed. Tuning up the optimization will happen in the future. </p> <p> I'll leave this bug in the database as a reminder that this work needs to be done. </p> <p> HTH </p> <p> Jeremy </p>
tsuckow commented almost 13 years ago

Thanks for taking a look at it since my toolchain is still compiling...

I figured it was a low priority but it will never be fixed if you don't know about it. I don't expect most people look at the generated assembly (I only did to squeeze some cycles in an interrupt).

Regards, Thomas

jeremybennett commented almost 13 years ago
<p> Hi Thomas </p> <p> Thanks very much for reporting it, and keep on reporting any other oddities you find. We hope to keep working on the tool chain, so all your input is much appreciated. </p> <p> Jeremy </p>
jeremybennett commented over 12 years ago
<p> Transferred to OpenRISC bugzilla (<a href="http://bugzilla.opencores.org/show_bug.cgi?id=49">Bug 49</a>). </p> <p> Marking closed in this bugtracker. </p>
jeremybennett closed this over 12 years ago

Assignee
jeremybennett
Labels
Request