I have a single issue pipeline that I need to schedule more accurately. For
the most part this is fine but the CPU is a 32-bit design but for 64-bit
opcodes (DImode or DFmode) I need to generate 2 opcodes and not one, but these
only appear as a single instruction until after reload has run.
On 23 Mar 2010, at 22:30, Steven Bosscher wrote:
On Tue, Mar 23, 2010 at 7:05 PM, Ian Bolton bol...@icerasemi.com wrote:
Is there any reason why BB reorder has been disabled
in bb-reorder.c for -Os, such that you can't even
turn it on with -freorder-blocks?
No, you should have the option
Is there any obvious reason why this function doesn't enable folding if we're
optimizing for size? All of the other string/memory folds appear to rely on the
various move, clear or set ratios?
When optimizing small string copies it's definitely smaller to do this inline
on some ISAs.
Thanks,
On 22 Mar 2010, at 17:44, Ian Bolton wrote:
Enabling BB-reorder only if profile info is available, is not the
right way to go. The compiler really doesn't place blocks in sane
places without it -- and it shouldn't have to, either. For example if
you split an edge at some point, the last thing
We only had one real 8-bit accumulator on that port (the W register) which we
did not expose the RA, instead exposing 32 virtual 8-bit registers from which
we could construct 8, 16, 32 and 64-bit pairs. The key to really good code
generation was to aggresively split the larger
I've been working on instruction scheduling issues for our (Ubicom) ISA
and have run into a problem I can't seem to resolve.
The pipeline has a major hazard associated with the generation of
addresses that are loaded from memory - the hazard window is 4
instructions. This is more than enough
On Mon, 2009-11-09 at 14:13 +, Ian Bolton wrote:
Dave Hudson wrote:
I've been working on gcc for an ISA (Ubicom32) that seems to have some
similarities to the problem you're seeing (we have some regs that can
be
used for many things but not all) and was seeing a ton a pointless
Jeff Law wrote:
Dave Hudson wrote:
I would have hoped that having done the analysis early on that the
register allocator would try to allocate from the preferred register
class rather than the cover class but it seems that doesn't happen?
So you're saying that the register preferences look
I'm looking at a problem with the gcc 4.4.0 port I'm supporting where
the architecture has separate address and data registers. In order to
get good code generation we need a single cover class to cover both the
data and address register classes as moving between them is no more
expensive
Alan Lehotsky wrote:
Look at the implementation of the IP2K compiler and linker.
It uses a segmented paged architecture just like the machine you are
describing.
In essence what we did was implement linker relaxation to deal with this.
When we called any function, we emitted the appropriate
FWIW we did get really great code generation for the IP2k in the end
although it took some rather unpleasant machine-dependent-reorg stuff to
work around the fact almost every instruction used a singe 8-bit
accumulator registerr :-)
Other ports to look at would be the AVR (8-bit RISC with 32
11 matches
Mail list logo
