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 thing
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 time
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 pseudo-operatio
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 las
On 23 Mar 2010, at 22:30, Steven Bosscher wrote:
> On Tue, Mar 23, 2010 at 7:05 PM, Ian Bolton 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 to turn it on
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,
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 lo
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 than
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 prefer
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. Wh
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 regis
11 matches
Mail list logo
