I'm working on a gcc backend for an architecture. The architecture has
instructions for indexed array access; so, ld r0, (r1, r2) is equivalent
to r0 = r1[r2] where r1 is a int32_t*.
I'm representing this in the .md file with the following pattern:
(define_insn "*si_load_indexed"
[
(set
I think I have found a bug. This is in stock gcc 4.8.1...
My backend does not use the 'enabled' attribute; therefore the following
code in insn-attr.h kicks in:
#ifndef HAVE_ATTR_enabled
#define HAVE_ATTR_enabled 0
#endif
Therefore the following code in gcc/lra-constraints.c is enabled:
Michael Matz wrote:
[...]
> As you didn't adjust any cost I would guess the high value comes from the
> default implementation of address_cost, which simply uses arithmetic cost,
> and the MULT in there is quite expensive by default.
>
> See TARGET_ADDRESS_COST in several ports.
Oddly, TARGET_A
So I'm trying to get compare-and-branch working on my architecture. I
have the following patterns:
(define_expand "cbranchsf4"
[(set
(reg:CC CC_REGNO)
(compare:CC
(match_operand:SF 1 "register_operand")
(match_operand:SF 2 "register_operand")))
(set
(pc)
Konstantin Vladimirov wrote:
[...]
> x = (y & ~(1 << 7)) | (((value >> 9) & 1) << 7);
[...]
> x = y & 4294967167 | (value >> 9) << 7 & 255; <- WAT?
((value >> 9) & 1) << 7
== ((value >> 9) << 7) & (1 << 7)
== ((value >> 9) << 7) & 0x80
== ((value >> 9) << 7) & 0xff
...I think.
That l
David Given wrote:
[...]
> When I actually try to build stuff, however, the branch gets emitted but
> then silently deleted during the mach pass.
Solved: turned out to be old code in the TARGET_MACHINE_DEPENDENT_REORG,
dating from the port I was basing my backend on, which was mangling my
c
I am having a great deal of trouble getting register elimination (and
stack frame layouts in general) working properly on my architecture.
There is some fundamental issue I'm simply not getting here.
My architecture is a fairly vanilla RISC system with a link pointer. The
stack frame layout I'm ai
David Malcolm wrote:
[...]
> Out of interest, how portable is open_memstream (and if not, is there a
> good portable way of doing this)? I have to do similar things in my
> python plugin for GCC, and currently I'm using fmemopen. IIRC that
> latter one is not available on OS X, and was one of the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/11/13 19:48, Mischa Baars wrote:
[...]
> I have written a couple of new trigonometric functions for use in
> the library, and actually I need this to function properly.
The point is that 1.1 simply cannot be represented precisely as a IEEE
float
