--- Comment #15 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
22:12 ---
(In reply to comment #13)
(In reply to comment #11)
The main concern on the recent LKML thread appeared to be code size rather
than
speed.
One should note this only helps CISC based processors
--- Comment #14 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
22:08 ---
(In reply to comment #7)
One should note this is actually hard to do without changing the code for 3506
also.
And of course if the volatile variable in the 3506 example code was an MMIO
register
at gcc dot gnu dot org
ReportedBy: paulmck at linux dot vnet dot ibm dot com
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33102
--- Comment #2 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
00:11 ---
Hmmm... I wasn't asking for volatile to be atomic, just for it to avoid
generating unnecessary code.
--
paulmck at linux dot vnet dot ibm dot com changed:
What|Removed
--- Comment #6 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:04 ---
(In reply to comment #4)
It is still the same issue.
Perhaps I am missing something, but I don't know of any hardware that would
react differently to this two-instruction sequence:
movli
--- Comment #11 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:21 ---
(In reply to comment #10)
Actually as I understand it, the expanded version is slightly faster under
newer x86's anyways as they don't have an extra decode stage.
The main concern on the recent LKML
--- Comment #12 from paulmck at linux dot vnet dot ibm dot com 2007-08-18
01:23 ---
(In reply to comment #9)
s/debian/Ubuntu/
Please accept my apologies for skipping that step -- I wasn't aware of this.
Should I replicate this bug at Ubuntu, or is this strictly advice for future
bug
