Re: Question on ARM legitimate address for DImode
On Tue, 2010-12-21 at 12:12 +0800, Jie Zhang wrote:
> Hi,
>
> While working on a bug, I found some code in ARM port that I don't
> understand.
>
> In ARM_LEGITIMIZE_RELOAD_ADDRESS and arm_legitimize_address, we allow a
> very small offset for DImode addressing.
>
> In ARM_LEGITIMIZE_RELOAD_ADDRESS:
>
> if (MODE == DImode || (MODE == DFmode && TARGET_SOFT_FLOAT)) \
>low = ((val & 0xf) ^ 0x8) - 0x8; \
>
> In arm_legitimize_address
>
>/* VFP addressing modes actually allow greater offsets, but for
> now we just stick with the lowest common denominator. */
>if (mode == DImode
>|| ((TARGET_SOFT_FLOAT || TARGET_VFP) && mode == DFmode))
> {
>low_n = n & 0x0f;
>n &= ~0x0f;
>if (low_n > 4)
> {
>n += 16;
>low_n -= 16;
> }
> }
>
> AFAIK, we could use two LDRs, or one LDRD, or one VLDR to access DImode
> in memory when the address is in the form of (REG + CONST_INT). The
> offset ranges for these three cases are:
>
> LDR -4095,4091
> LDRD -255,255
> VLDR -1020,1020 && (ADDR & 3) == 0
The original code was designed to exploit LDM(IA,IB,DB,DA) which would
have the offset ranges described. On earlier ARM chips (certainly up to
and including ARM7TDMI) it was a significant win to do it that way (add
a constant to the address register and then use LDM was faster than two
LDR instructions).
That's no-longer true on modern chips, LDM is often slower than
individual LDR insns now.
>
> so the lowest common denominator is
>
> -1020,1020 && (ADDR & 3) == 0 if ! TARGET_LDRD
> -255,255 && (ADDR & 3) == 0 if TARGET_LDRD
>
> Both are much larger than what we have now in the ARM port.
>
> Did I miss some other cases? That two pieces of code are rather old
> (more than 15 years). The main code was added by
>
> svn: revision 7536 by erich, Thu Jun 23 16:02:41 1994 UTC in arm.h
> git: fac435147512513c1b8fa55bee061c8e3a767ba9
> log: (LEGITIMIZE_ADDRESS): Push constants that will never be legitimate
> -- symbols
> and labels -- into registers. Handle DImode better.
>
> I checked out that revision to take a look but didn't find an obvious
> reason for such small index range. Did I miss something tricky?
>
> If there is nothing I missed, I'd like to propose the attached patch.
>
>
> Regards,
Re: How can I add 256bits register file to a MIPS port?
2010/12/21 Ian Lance Taylor : > Liu writes: > >> I need add 256bits-register support for our MIPS-based >> processor, so I add some codes. >> When I build gcc and test it, get a error "unable to find a >> register to spill in class 'XX_REGS'" >> can you tell me how to add 256bits register file to a MIPS port? >> >> Thanks! >> >> codes: >> gcc/config/mips/constraints.md : >> (define_register_constraint 'Z' 'XX_REGS' >> '@internal') >> >> gcc/config/mips/mips-ftypes.def : >> DEF_MIPS_FTYPE (2, (UV32QI, UV32QI, UV32QI)) >> DEF_MIPS_FTYPE (2, (V32QI, V32QI, V32QI)) >> >> gcc/config/mips/mips.h : >> #define FIXED_REGISTERS >> /* XX regusters */ \ >> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \ >> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \ >> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, \ >> 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1 \ > > Setting them all as 1 in FIXED_REGISTERS means that gcc can't use them. > > Ian > Thank you for reply. I changed FIXED_REGISTERS into 0, FIXED_REGISTERS into 1, CALL_REALLY_USED_REGISTERS into 1. build and test it, but I still get the same error.
libquadmath: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
Hi, I was experimenting with adding microblaze-rtems* and got this error: checking how to run the C preprocessor... /users/joel/test-gcc/b-gcc1-microblaze/./gcc/xgcc -B/users/joel/test-gcc/b-gcc1-microblaze/./gcc/ -nostdinc -B/users/joel/test-gcc/b-gcc1-microblaze/microblaze-rtems4.11/newlib/ -isystem /users/joel/test-gcc/b-gcc1-microblaze/microblaze-rtems4.11/newlib/targ-include -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include -B/users/joel/test-gcc/install-svn/microblaze-rtems4.11/bin/ -B/users/joel/test-gcc/install-svn/microblaze-rtems4.11/lib/ -isystem /users/joel/test-gcc/install-svn/microblaze-rtems4.11/include -isystem /users/joel/test-gcc/install-svn/microblaze-rtems4.11/sys-include-E checking for sqrtl in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libquadmath] Error 1 This looks like it isn't specific to what I am doing. Any suggestions? Thanks. --joel sherrill RTEMS
Re: How can I add 256bits register file to a MIPS port?
Liu writes: > I changed FIXED_REGISTERS into 0, FIXED_REGISTERS into 1, > CALL_REALLY_USED_REGISTERS into 1. > > build and test it, but I still get the same error. Have you updated HARD_REGNO_MODE_OK? I encourage you to carefully read the gcc internals manual. It's pretty good on this kind of thing. Ian
Re: libquadmath: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
On 21/12/2010 14:51, Joel Sherrill wrote: > checking how to run the C preprocessor... > /users/joel/test-gcc/b-gcc1-microblaze/./gcc/xgcc > -B/users/joel/test-gcc/b-gcc1-microblaze/./gcc/ -nostdinc > -B/users/joel/test-gcc/b-gcc1-microblaze/microblaze-rtems4.11/newlib/ > -isystem > /users/joel/test-gcc/b-gcc1-microblaze/microblaze-rtems4.11/newlib/targ-include > -isystem /users/joel/test-gcc/gcc-svn/newlib/libc/include > -B/users/joel/test-gcc/install-svn/microblaze-rtems4.11/bin/ > -B/users/joel/test-gcc/install-svn/microblaze-rtems4.11/lib/ -isystem > /users/joel/test-gcc/install-svn/microblaze-rtems4.11/include -isystem > /users/joel/test-gcc/install-svn/microblaze-rtems4.11/sys-include-E > checking for sqrtl in -lm... configure: error: Link tests are not > allowed after GCC_NO_EXECUTABLES. > make[1]: *** [configure-target-libquadmath] Error 1 This is PR46520. There's also a current thread about it on -patches, subject "[Build, Patch, libquadmath] PR 46520 Do not call AC_CHECK_LIB for gcc_no_link". cheers, DaveK
Re: libquadmath: configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
Joel Sherrill wrote: I was experimenting with adding microblaze-rtems* and got this error: > checking for sqrtl in -lm... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. make[1]: *** [configure-target-libquadmath] Error 1 I am puzzled: While this issue existed, it should be fixed as configure.ac now contains: if test x$gcc_no_link != xyes; then AC_CHECK_LIB([m],[sqrtl],[AC_DEFINE([HAVE_SQRTL],[1], [libm includes sqrtl])]) AC_CHECK_LIB([m],[cbrtl],[AC_DEFINE([HAVE_CBRTL],[1], [libm includes cbrtl])]) else ... This part has been committed Sun Dec 19 19:01:38 2010 +. Thus, the big question is: Why does it not work for you? If you have an older version: Can you try again? And please report the result, namely: Does it work now or is there another additional issue? If you have the current version: Well, then I am completely puzzled - and you need to do more debugging work. Tobias PS: A work around is --disable-libquadmath; however, the idea (PR 46520) is to have this completely fixed. Thus, I would prefer if you do not use the work around and rather check whether it is now working.
gcc-4.4-20101221 is now available
Snapshot gcc-4.4-20101221 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20101221/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 168133 You'll find: gcc-4.4-20101221.tar.bz2 Complete GCC (includes all of below) MD5=e6e21b83d0f885c16603fac7fe842fc9 SHA1=c1964eb0cfcf74a63090fe39086014afe4b7a42e gcc-core-4.4-20101221.tar.bz2C front end and core compiler MD5=922dcdb0c4ebf1965b946ee770ef3f1b SHA1=dc7eeaf1d96a49b1e4e1438ff330020c8d75d7ac gcc-ada-4.4-20101221.tar.bz2 Ada front end and runtime MD5=92dd38565f268e5854e56bee1e6e1983 SHA1=67c77455904e0e434c2e727c7a7de78bf6a06183 gcc-fortran-4.4-20101221.tar.bz2 Fortran front end and runtime MD5=0797f5a4dc3b2c7c4c00f0f7ff6b7862 SHA1=5f59ad2ef8cf06092600936fb73a3af5241ce5db gcc-g++-4.4-20101221.tar.bz2 C++ front end and runtime MD5=56ee55f7ba17ddd438524c34ab2472b0 SHA1=43ca2585f66dcbb40b3a8ae7d517b915b2418f45 gcc-go-4.4-20101221.tar.bz2 Go front end and runtime MD5=07c7ed2530f5262e80cd5d1550b44d46 SHA1=22845da5a3e9fcd5f7bb1d9a55937ccdf22c gcc-java-4.4-20101221.tar.bz2Java front end and runtime MD5=901334afe260ece6749c3d172af7099e SHA1=d4a022fe19acea9a114a49d4b8ac0949feac448f gcc-objc-4.4-20101221.tar.bz2Objective-C front end and runtime MD5=31643d374f06eb8111a41f6025d40125 SHA1=ddf37ca431c7a23cb15fb7997aaeb635c0da156a gcc-testsuite-4.4-20101221.tar.bz2 The GCC testsuite MD5=758b3dae987f86e056554468da61dcf4 SHA1=71f58b17c6b976dc53393ebcdcc8f832583e6eed Diffs from 4.4-20101214 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Question on ARM legitimate address for DImode
On 12/21/2010 06:12 PM, Richard Earnshaw wrote:
On Tue, 2010-12-21 at 12:12 +0800, Jie Zhang wrote:
Hi,
While working on a bug, I found some code in ARM port that I don't
understand.
In ARM_LEGITIMIZE_RELOAD_ADDRESS and arm_legitimize_address, we allow a
very small offset for DImode addressing.
In ARM_LEGITIMIZE_RELOAD_ADDRESS:
if (MODE == DImode || (MODE == DFmode&& TARGET_SOFT_FLOAT)) \
low = ((val& 0xf) ^ 0x8) - 0x8; \
In arm_legitimize_address
/* VFP addressing modes actually allow greater offsets, but for
now we just stick with the lowest common denominator. */
if (mode == DImode
|| ((TARGET_SOFT_FLOAT || TARGET_VFP)&& mode == DFmode))
{
low_n = n& 0x0f;
n&= ~0x0f;
if (low_n> 4)
{
n += 16;
low_n -= 16;
}
}
AFAIK, we could use two LDRs, or one LDRD, or one VLDR to access DImode
in memory when the address is in the form of (REG + CONST_INT). The
offset ranges for these three cases are:
LDR -4095,4091
LDRD -255,255
VLDR -1020,1020&& (ADDR& 3) == 0
The original code was designed to exploit LDM(IA,IB,DB,DA) which would
have the offset ranges described. On earlier ARM chips (certainly up to
and including ARM7TDMI) it was a significant win to do it that way (add
a constant to the address register and then use LDM was faster than two
LDR instructions).
That's no-longer true on modern chips, LDM is often slower than
individual LDR insns now.
Thanks! Now I see. So I think the original code is still needed but
should be used only for such earlier ARM chips. I will send the updated
patch to gcc-patches mailing list.
--
Jie Zhang
