Richard Sandiford wrote:
Returning to this old thread...
Richard Sandiford writes:
Tejas Belagod writes:
When I relaxed CANNOT_CHANGE_MODE_CLASS to undefined for AArch64,
gcc.c-torture/execute/copysign1.c generates incorrect code because LRA cannot
seem to handle subregs like
(subreg:DI
Hi,
Are there any tricks I can use to debug an LTO ICE? Lto1 --help does not seem to
give me an option to output trace dumps etc.
What I suspect is happening is that cc1 builds erroneous LTO IR info in the
objects that causes the ICEs. Is there a reader that will dump the IR from these
LTO obj
On 24/10/14 15:44, Segher Boessenkool wrote:
On Thu, Oct 23, 2014 at 06:52:20PM +0100, Charles Baylis wrote:
( tl;dr: How do I handle intrinsic or builtin functions where there
are restrictions on the arguments which can't be represented in a C
function prototype? Do other ports have this proble
On 29/10/14 09:32, Richard Biener wrote:
On Tue, Oct 28, 2014 at 4:55 PM, Evandro Menezes wrote:
While doing some benchmark flag mining on AArch64, I noticed that
-fpeel-loops was a mined option often. As a matter of fact, when using it
always, even without FDO, it seemed to raise most benchma
on.h is
already dependent on the specific versions of gcc, this maintainance overhead is
probably unavoidable. We do need standard typedefs from somewhere...
Thoughts?
Thanks,
Tejas Belagod.
ARM.
In this way, it is much easier to support NEON intrinsics in
environments that we care about (
Ard Biesheuvel wrote:
On 18 July 2013 16:54, Tejas Belagod wrote:
I'd like to follow up this thread to move towards removing arm_neon.h's
dependence on stdint.h. My comments inline below.
As far as I can tell, the only dependency arm_neon.h has on the
contents of that header are th
Hi,
I'm looking for some help understanding how BIT_FIELD_REFs work with big-endian.
Vector subscripts in this example:
#define vector __attribute__((vector_size(sizeof(int)*4) ))
typedef int vec vector;
int foo(vec a)
{
return a[0];
}
gets lowered into array accesses by c-typeck.c
;; Fu
What's interesting to me here is the bitpos - does this not need
BYTES_BIG_ENDIAN correction? This seems to be inconsistenct with what happens
with reduction operations in the autovectorizer where the scalar result in the
reduction epilogue gets extracted with a BIT_FIELD_REF but the bitpos ther
Hi,
I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all mode
changes on FP_REGS as aarch64 does not have register-packing, but I'm running
into an LRA ICE. A test case generates an RTL subreg of the following form
(set (reg:DF 97) (subreg:DF (reg:V2DF 95) 8))
LRA ha
Vladimir Makarov wrote:
On 12/4/2013, 6:15 AM, Tejas Belagod wrote:
Hi,
I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all
mode changes on FP_REGS as aarch64 does not have register-packing, but
I'm running into an LRA ICE. A test case generates an RTL subreg of the
ll is well.
Thanks,
Tejas Belagod
ARM.
Vladimir Makarov wrote:
On 12/5/2013, 9:35 AM, Tejas Belagod wrote:
Vladimir Makarov wrote:
On 12/4/2013, 6:15 AM, Tejas Belagod wrote:
Hi,
I'm trying to relax CANNOT_CHANGE_MODE_CLASS for aarch64 to allow all
mode changes on FP_REGS as aarch64 does not have register-packing, but
I'
12 matches
Mail list logo
