[MIPS] MADD issue
Hi Richard,
After tracing GCC 4.x to see why MADD is not generated for MIPS32,
I found out the main issue is that the pattern "adddi3"
is not available for MIPS32. Because the missing
of adddi3, GCC 4.x needs to split 64-bit addition to 4 separate
RTL insns. This leads to that the combining phase fails
to combine RTL insns to a single madd pattern.
Could we enable "adddi3" for MIPS32 in GCC 4.x? Or is there a
better way to generate MADD? Thanks a lot!
Ex: (b67.c)
long long test (long long a, int b, int c)
{
return a + (long long) b * (long long) c;
}
# gcc -S b67.c -O3 -mips32
(b67.s)
test:
.frame $sp,0,$31
.mask 0x,0
.fmask 0x,0
.setnoreorder
.setnomacro
mtlo$5
mthi$4
madd$6,$7
mflo$3
j $31
mfhi$2
Regards,
Chao-ying
-
Ex: (mips.md in GCC 3.4)
(define_expand "adddi3"
[(parallel [(set (match_operand:DI 0 "register_operand" "")
(plus:DI (match_operand:DI 1 "register_operand" "")
(match_operand:DI 2 "arith_operand" "")))
(clobber (match_dup 3))])]
"TARGET_64BIT || (!TARGET_DEBUG_G_MODE && !TARGET_MIPS16)"
{
(define_insn "adddi3_internal_1"
[(set (match_operand:DI 0 "register_operand" "=d,&d")
(plus:DI (match_operand:DI 1 "register_operand" "0,d")
(match_operand:DI 2 "register_operand" "d,d")))
(clobber (match_operand:SI 3 "register_operand" "=d,d"))]
"!TARGET_64BIT && !TARGET_DEBUG_G_MODE && !TARGET_MIPS16"
{
return (REGNO (operands[0]) == REGNO (operands[1])
&& REGNO (operands[0]) == REGNO (operands[2]))
? "srl\t%3,%L0,31\;sll\t%M0,%M0,1\;sll\t%L0,%L1,1\;addu\t%M0,%M0,%3"
:
"addu\t%L0,%L1,%L2\;sltu\t%3,%L0,%L2\;addu\t%M0,%M1,%M2\;addu\t%M0,%M0,%3";
}
[(set_attr "type" "darith")
(set_attr "mode" "DI")
(set_attr "length" "16")])
(define_insn "*smul_acc_di"
[(set (match_operand:DI 0 "register_operand" "=x")
(plus:DI
(mult:DI (sign_extend:DI (match_operand:SI 1 "register_operand" "d"))
(sign_extend:DI (match_operand:SI 2 "register_operand" "d")))
(match_operand:DI 3 "register_operand" "0")))]
"(TARGET_MAD || ISA_HAS_MACC)
&& !TARGET_64BIT"
{
if (TARGET_MAD)
return "mad\t%1,%2";
else if (TARGET_MIPS5500)
return "madd\t%1,%2";
else
return "macc\t%.,%1,%2";
}
[(set_attr "type" "imadd")
(set_attr "mode" "SI")])
-
RE: [MIPS] MADD issue
Hi,
How about a patch like this to support signed and unsigned
multiplication and addition? We can extend to MSUB/MSUBU as well.
Thanks!
2007-04-20 Chao-ying Fu <[EMAIL PROTECTED]>
* optabs.c (init_optabs): Initialize smadd_widen_optab and
umadd_widen_optab.
* optabs.h (optab_index): Add OTI_smadd_widen and OTI_umadd_widen.
(smadd_widen_optab, umadd_widen_optab): Define.
* genopinit.c (optabs): Add smadd_widen_optab and usmadd_widen_optab.
* expr.c (expand_expr_real_1): Add rtx of op2.
Process PLUS_EXPR to generate multiplication and add instructions.
* config/mips/mips-dspr2.md (maddsidi4, umaddsidi4): New patterns.
Ex: (bug72.c)
long long t1 (int a, int b, long long c)
{
return (long long)a * b + c;
}
unsigned long long t2 (unsigned int a, unsigned int b, unsigned long long c)
{
return (unsigned long long)a * b + c;
}
# <812> ~/dev/gcc4x/install32/bin/mipsisa32r2-elf-gcc -S -mdspr2 bug72.c -O
t1:
mtlo$7
mthi$6
madd$ac0,$5,$4
mflo$7
mfhi$6
move$2,$6
j $31
move$3,$7
t2:
mtlo$7
mthi$6
maddu $ac0,$5,$4
mflo$7
mfhi$6
move$2,$6
j $31
move$3,$7
Regards,
Chao-ying
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> Richard Sandiford
> Sent: Friday, April 20, 2007 8:05 AM
> To: Stephens, Nigel
> Cc: Fu, Chao-Ying; gcc@gcc.gnu.org; Thekkath, Radhika
> Subject: Re: [MIPS] MADD issue
>
>
> Nigel Stephens <[EMAIL PROTECTED]> writes:
> > OK, so maybe as the person who removed adddi3 from the MIPS
> backend, and
> > the main proponent of the new fused opcodes, you get to
> volunteer to
> > implement this? :)
>
> Hey, I was pretty happy with the status quo ;)
>
> Richard
>
gcc.diff
Description: gcc.diff
RE: Problem with patch for PR tree-optimization/29789
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of
> H. J. Lu
> Sent: Wednesday, April 25, 2007 2:02 PM
> To: Steve Ellcey
> Cc: [EMAIL PROTECTED]; gcc@gcc.gnu.org
> Subject: Re: Problem with patch for PR tree-optimization/29789
>
>
> On Wed, Apr 25, 2007 at 01:55:14PM -0700, Steve Ellcey wrote:
> > Richard,
> >
> > Has anyone reported any problems with your
> tree-ssa-loop-im.c patch that
> > fixes PR tree-optimization/29789? I have been looking at a
> failure with
> > the SPECfp2000 173.applu test. I found that if I compile it with
> > version r124041 of the GCC gfortran compiler it works but
> if I compile
> > it with version r124042 it fails. The difference between the two is
> > your checkin:
> >
>
> See
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31703
>
>
> H.J.
>
I got a test that fails for mips32r2-elf. Is this fail from the same issue?
(bug74.c)
void test (long long mod, long long temp)
{
while (1)
{
int leftmost = (mod >> 1) & 1;
mod = mod << 1;
if (leftmost)
mod = temp;
}
}
# mipsisa32r2-elf-gcc -S bug74.c -O -fdump-tree-all
bug74.c: In function â?~testâ?T:
bug74.c:5: internal compiler error: in simplify_subreg, at simplify-rtx.c:4677
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
(bug74.c.119t.blocks)
;; Function test (test)
test (mod, temp)
{
long long int mod.25;
int leftmost;
:;
:;
mod.25 = mod;
:;
leftmost = mod.25 & 2;
mod.25 = mod.25 << 1;
mod = temp;
if (leftmost != 0) goto ; else goto ;
}
NOTE that there should be a type cast to int for this statement
"leftmost = mod.25 & 2;".
Regards,
Chao-ying
RE: [MIPS] Test case dspr2-MULT is failed
Chung-Lin Tang wrote:
> I analyzed this testcase regression a while earlier; the
> direct cause of
> this is due to mips_order_regs_for_local_alloc(), which now serves as
> MIPS' ADJUST_REG_ALLOC_ORDER macro.
>
> The mips_order_regs_for_local_alloc() function seems to be written for
> the old local-alloc.c, still left as the deprecated
> ORDER_REGS_FOR_LOCAL_ALLOC macro after the transition to IRA (actually
> not called at all during then), and relatively recently
> 'revived' after
> a patch by Bernd that created the ADJUST_REG_ALLOC_ORDER
> macro went in.
>
> So you have a local-alloc.c heuristic working in IRA, which seemed to
> cause these regressions.
>
> Removing mips_order_regs_for_local_alloc() will let this
> testcase pass;
> of course the real fix should be to review the MIPS
> reg-ordering logic,
> left for you MIPS people...
I think your analysis is correct. We should just delete
mips_order_regs_for_local_alloc()
in mips.c and delete ADJUST_REG_ALLOC_ORDER in mips.h.
Then, 3 accumulators can be used in dspr2-MULT.c and dspr2-MULTU.c now. Thanks!
Ex:
/* Test MIPS32 DSP REV 2 MULT instruction. Tune for a CPU that has
pipelined mult. */
/* { dg-do compile } */
/* { dg-options "-mgp32 -mdspr2 -O2 -ffixed-hi -ffixed-lo -mtune=74kc" } */
/* { dg-final { scan-assembler "\tmult\t" } } */
/* { dg-final { scan-assembler "ac1" } } */
/* { dg-final { scan-assembler "ac2" } } */
/* { dg-final { scan-assembler "ac3" } } */
typedef long long a64;
NOMIPS16 a64 test (a64 *a, int *b, int *c)
{
a[0] = (a64) b[0] * c[0];
a[1] = (a64) b[1] * c[1];
a[2] = (a64) b[2] * c[2];
}
Ex:
/* Test MIPS32 DSP REV 2 MULTU instruction. Tune for a CPU that has
pipelined multu. */
/* { dg-do compile } */
/* { dg-options "-mgp32 -mdspr2 -O2 -ffixed-hi -ffixed-lo -mtune=74kc" } */
/* { dg-final { scan-assembler "\tmultu\t" } } */
/* { dg-final { scan-assembler "ac1" } } */
/* { dg-final { scan-assembler "ac2" } } */
/* { dg-final { scan-assembler "ac3" } } */
typedef unsigned long long a64;
NOMIPS16 a64 test (a64 *a, unsigned int *b, unsigned int *c)
{
a[0] = (a64) b[0] * c[0];
a[1] = (a64) b[1] * c[1];
a[2] = (a64) b[2] * c[2];
}
Regards,
Chao-ying
RE: [MIPS] Test case dspr2-MULT is failed
Mingjie Xing wrote:
> 2011/2/18 Fu, Chao-Ying :
> > I think your analysis is correct. We should just delete
> mips_order_regs_for_local_alloc()
> > in mips.c and delete ADJUST_REG_ALLOC_ORDER in mips.h.
> > Then, 3 accumulators can be used in dspr2-MULT.c and
> dspr2-MULTU.c now. Thanks!
>
> /* ADJUST_REG_ALLOC_ORDER is a macro which permits reg_alloc_order
>to be rearranged based on a particular function. On the mips16, we
>want to allocate $24 (T_REG) before other registers for
>instructions for which it is possible. */
>
> #define ADJUST_REG_ALLOC_ORDER mips_order_regs_for_local_alloc ()
>
> I'm just wondering if it Is appropriate to simply remove
> ADJUST_REG_ALLOC_ORDER considering its comment.
Ok. Need to test if allocating $24 first is still better in MIPS16 under IRA.
If yes, we should update mips_order_regs_for_local_alloc() for MIPS16 only
(eg: exchange $24 and $1), as the default register order is as follows.
Ex:
/* We generally want to put call-clobbered registers ahead of
call-saved ones. (IRA expects this.) */
#define REG_ALLOC_ORDER \
{ /* Accumulator registers. When GPRs and accumulators have equal \
cost, we generally prefer to use accumulators. For example, \
a division of multiplication result is better allocated to LO, \
so that we put the MFLO at the point of use instead of at the \
point of definition. It's also needed if we're to take advantage \
of the extra accumulators available with -mdspr2. In some cases, \
it can also help to reduce register pressure. */ \
64, 65,176,177,178,179,180,181, \
/* Call-clobbered GPRs. */ \
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15,\
24, 25, 31, \
...
Regards,
Chao-ying
RE: FDO and LTO on ARM
> > I identified the libstdc++ failure as a problem when building gcc: > > configure:16321: /tmp/build-ndk/gcc-4.7.0/./gcc/xgcc > -shared-libgcc -B/tmp/build-ndk/gcc-4.7.0/./gcc -nostdinc++ > -L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/ > src > -L/tmp/build-ndk/gcc-4.7.0/arm-linux-androideabi/libstdc++-v3/ > src/.libs > -B/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/p > rebuilt/linux-x86/arm-linux-androideabi/bin/ > -B/tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/p > rebuilt/linux-x86/arm-linux-androideabi/lib/ -isystem > /tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/pre > built/linux-x86/arm-linux-androideabi/include -isystem > /tmp/android-ndk-r6/toolchains/arm-linux-androideabi-4.7.0/pre > built/linux-x86/arm-linux-androideabi/sys-include-c > -frtti -fexceptions -O2 -Os -g -DTARGET_POSIX_IO > -fno-short-enums conftest.cpp >&5 > conftest.cpp:35:18: error: 'INT_MIN' was not declared in this scope > conftest.cpp:36:18: error: 'INT_MAX' was not declared in this scope > (snip) > configure:16345: checking for enabled wchar_t specializations > configure:16347: result: no > I hit the same issue sometime ago. This is a bug in NDK platform android-9 "wchar.h". To fix it, just add into wchar.h. Ex: # git diff wchar.h diff --git a/ndk/platforms/android-9/include/wchar.h b/ndk/platforms/android-9/i index 9b744a5..fb8714c 100644 --- a/ndk/platforms/android-9/include/wchar.h +++ b/ndk/platforms/android-9/include/wchar.h @@ -38,6 +38,7 @@ #include #include #include +#include #include Regards, Chao-ying
[MIPS] cannot split restore_gp
Hi,
G++ could not split restore_gp.
Please check this test (from #line 15017 "configure" of
gcc/libstdc++-v3/).
# cat foo.cpp
struct S { ~S(); };
void bar();
void foo()
{
S s;
bar();
}
# ~/dev/gcc45/build/gcc/cc1plus -quiet foo.cpp -o foo.s -mno-shared -mplt
-mabicalls -G0
foo.cpp: In function â?~foo()â?T:
foo.cpp:7:1: error: could not split insn
(insn 29 28 30 (parallel [
(set (reg:SI 28 $28)
(unspec_volatile:SI [
(const_int 0 [0x0])
] 7))
(clobber (reg:SI 2 $2))
]) 555 {restore_gp} (nil))
foo.cpp:7:1: internal compiler error: in final_scan_insn, at final.c:2651
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
--
Something may be wrong before we reach the "final" pass.
(Or, we should have split restore_gp earlier.)
Any idea? Thanks!
Regards,
Chao-ying
RE: question: suffix for fixed-point literal constant
Janis Johnson wrote: > > I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix > suffixes in decimal float literal constants for c/33466. While I'm at > it I'm fixing suffixes for fixed-point literal constants. > Currently for > fixed-point GCC accepts any ordering of the letters in the > suffix. The > technical report (N1169) gives specific strings, not > individual letters > that can be used in any order. That seems like something > obvious to fix > but I thought I'd mention it in case they really should be accepted in > any order. > > My question, though, is about the case of the letters in the suffixes. > N1169 says "note that the suffix is case insensitive"; should I take > that literally and allow any mix of cases (as GCC currently does), or > require that the same case be used within a particular suffix? From my implementation, I allow mixed-case suffixes. We can view this as a GCC feature, if it turns out that the spec doesn't allow this. Thanks! Regards, Chao-ying
Re: question: suffix for fixed-point literal constant
"Janis Johnson" wrote: > On Wed, 2009-02-11 at 10:42 -0800, Fu, Chao-Ying wrote: > > Janis Johnson wrote: > > > > > > I'm rewriting function interpret_float_suffix in libcpp/expr.c to fix > > > suffixes in decimal float literal constants for c/33466. While I'm at > > > it I'm fixing suffixes for fixed-point literal constants. > > > Currently for > > > fixed-point GCC accepts any ordering of the letters in the > > > suffix. The > > > technical report (N1169) gives specific strings, not > > > individual letters > > > that can be used in any order. That seems like something > > > obvious to fix > > > but I thought I'd mention it in case they really should be accepted in > > > any order. > > > > > > My question, though, is about the case of the letters in the suffixes. > > > N1169 says "note that the suffix is case insensitive"; should I take > > > that literally and allow any mix of cases (as GCC currently does), or > > > require that the same case be used within a particular suffix? > > > > From my implementation, I allow mixed-case suffixes. > > We can view this as a GCC feature, if it turns out that the spec doesn't allow this. > > Thanks! > > Where do the 'll' and 'LL' come from in fixed-point suffixes? Is there > a reason that your implementation requires them to be the same case? > > Janis The spec doesn't have long long fixed-point types or constants. So, the long long fixed-point support in GCC is an extension to the spec. I just reused C code to enforce ll and LL. We are free to accept any formats. If you like, you can change C code to accept all of "ll, LL, Ll, lL". Thanks! Regards, Chao-ying
RE: generic bug in fixed-point constant folding
Sean D'Epagnier wrote: > > I think I found a generic problem for fixed point constant folding. > > In fold-const.c:11872 gcc tries to apply: > /* Transform (x >> c) << c into x & (-1< c) >> c > into x & ((unsigned)-1 >> c) for unsigned types. */ > > I attached a simple patch which fixes the problem by not applying this > optimization to fixed point types. I would like to have this > optimization because it is possible.. but the problem is fixed-point > types do not support bitwise operations like & | ^ ~.. so without > supporting these somehow internally but not allowing the user to have > them, this can't take place. > > I am open to other suggestions. For future reference should this be > posted as a bug report? It seems simple enough that it could be > included right away.. but I feel like if it's a bug report no one will > notice since fixed-point support is not widely used. > > Sean > Thanks for finding this bug and fixing it! I think you should send your patch to gcc-patc...@gcc.gnu.org, and check in this patch to mainline and 4.3 if possible. Regards, Chao-ying
Fixed-Point Arithmetic Project
Hello All, We are working on a project to add fixed-point arithmetic support to GCC. A GCC project description page is available here http://gcc.gnu.org/wiki/FixedPointArithmetic and we will create a GCC branch in the near future. If you have any suggestions or comments, please respond. Thanks a lot! Regards, Chao-ying
[MIPS64] Problems when Passing TImode Parameters in EABI
Hello,
I think there is a bug in mips_pass_by_reference when the mips abi
is EABI to pass TImode parameters.
The following code is from the mainline GCC "mips.c".
-
mips_pass_by_reference (CUMULATIVE_ARGS *cum ATTRIBUTE_UNUSED,
enum machine_mode mode, tree type,
bool named ATTRIBUTE_UNUSED)
{
if (mips_abi == ABI_EABI)
{
int size;
/* ??? How should SCmode be handled? */
if (type == NULL_TREE || mode == DImode || mode == DFmode)
return 0;
size = int_size_in_bytes (type);
return size == -1 || size > UNITS_PER_WORD;
}
else
{
/* If we have a variable-sized parameter, we have no choice. */
return targetm.calls.must_pass_in_stack (mode, type);
}
}
-
When "type" is NULL_TREE, this function returns "0". But when "type" is not
NULL and
the size of TImode is bigger than UNITS_PER_WORD, so it returns "1".
This causes inconsistency in the following test.
# cat timode.c
typedef int TItype __attribute__ ((mode (TI)));
TItype test1 (TItype a)
{
return a*a;
}
# mipsisa64-elf-gcc -S timode.c -O3
### timiode.s
test1:
daddiu $sp,$sp,-8
sd $31,0($sp)
ld $3,8($4) <- Parameter in stack
ld $2,0($4) <- Parameter in stack
move$7,$3 < Parameter in register
move$4,$2 < Parameter in register
move$5,$3 < Parameter in register
jal __multi3
move$6,$2 < Parameter in register
ld $31,0($sp)
move$4,$2
move$2,$4
j $31
daddiu $sp,$sp,8
Does someone know how to pass TImode parameters in EABI? Thanks!
Regards,
Chao-ying
RE: [GCC Steering Committee] Android sub-port reviewer
Richard Sandiford wrote: > Sent: Monday, April 02, 2012 11:45 AM > To: Maxim Kuvyrkov > Cc: Richard Earnshaw; Jan Hubicka; gcc@gcc.gnu.org > Subject: Re: [GCC Steering Committee] Android sub-port reviewer > > Maxim Kuvyrkov writes: > > On 29/03/2012, at 5:38 PM, Maxim Kuvyrkov wrote: > > > >> I volunteer as the reviewer for Android sub-port. > >> > >> Android/Bionic support is an extension over Linux port and > is being gradually added for more and more architectures. I > wrote the original Android GCC support for ARM (under a > watchful design eye of Joseph Myers), and know how the bits > fit together. > >> > >> As adding Android support to a new architecture requires > changes to that architecture, the architecture maintainer > will have the power of veto for the Android-related changes. > > > > One of the members of SC raised a good point about whether > architecture maintainers would prefer to handle the Android > patches themselves. My intention is to spare you the > additional headache of dealing with Android, but, well, maybe > you like it :-). > > > > Richard E., > > Jan, > > Richard S., > > > > Do you want to handle Android changes by yourself or do you > want to delegate? > > Having a separate maintainer of MIPS Android sounds good to me too > (and thanks for asking). As Richard E says, we should > probably coordinate > any changes to the generic MIPS files, but I wouldn't know > what's right > for Android-specific stuff. > > Richard > Hi All, We did the MIPS Android port, and here is the change that we submitted to googlesource. https://android-review.googlesource.com/#/c/34000/ Please check this file: 0007-gcc-mips.patch under ndk/build/tools/toolchain-patches/gcc after "git clone https://android.googlesource.com/platform/ndk"; (Or, https://android-review.googlesource.com/#/c/34000/2/build/tools/toolchain-patches/gcc/0007-gcc-mips.patch) It basically sets the MIPS target to little-endian MIPS32 for mips-linux-android. Also, it changes the GCC driver for MIPS Android. For MIPS Android unwinding supports, we add __BIONIC__ check to compile unwind-dw2-fde-glibc.c. We will be glad to help to merge code to GCC mainline. Thanks! Regards, Chao-ying
RE: [GCC Steering Committee] Android sub-port reviewer
Andrew Pinski wrote: > On Mon, Apr 2, 2012 at 1:55 PM, Fu, Chao-Ying wrote: > > It basically sets the MIPS target to little-endian MIPS32 > for mips-linux-android. > > That seems broken because mips-*-* is big-endian and mipsel-*-* is > little-endian. Is any way of fixing that before even trying to > submitting the patch? Because it will be the only port for mips which > is the opposite endian which makes it out of place. We fixed the MIPS target to little endian, because there is only one MIPS ABI in official NDK for Android: little-endian MIPS32 release 1. NDK scripts are tested with mips-linux-android. (We didn't test mipsel-linux-android targets.) Note that Android software components (ex: google v8, webkit jsc) may be coded for little-endian targets only. If GCC doesn't set the MIPS Android targets to little endian, it will be easy to add a small patch into googlesource in the future. Ex: Add -EL options for compilation/linking. Thanks! Regards, Chao-ying
RE: [GCC Steering Committee] Android sub-port reviewer
Andrew Pinski wrote: > The point is mips*-*-* is big endian and mipsel*-*-* is little endian. > And doing adding a target which says mips-linux-android which is > little-endian is just backwards. Is there anyway to fix the target > triplet to be mipsel-linux-android including inside the official NDK? > If not then we have a broken triplet for android. I agree with what you said. The simplest fix is that mips-linux-android still generates big-endian code as the MIPS target triplet design. Don't ever set it to generate little-endian code automatically. For MIPS GCC Android patches to merge to FSF GCC trunk, we will never change endiannes. Note that we did use a regular mips-linux-gnu GCC to compile Android systems by using -EL. The target of "mips-linux-android" is just invented to work with NDK scripts. And people can freely create "mipsel-linux-*" toolchains to compile Android systems directly, or create "mips-linux-*" toolchains to compile Android systems with -EL. The MIPS NDK script patch was just merged to googlesource last night. I can work on another patch to use -EL options, but to let "mips-linux-andoird" generate big-endian code. Is this solution ok for you? Thanks! Regards, Chao-ying
RE: [GCC Steering Committee] Android sub-port reviewer
Maxim Kuvyrkov wrote:
> I encourage you to submit the MIPS Android patches to
> gcc-patches@. And, as long as your changes preserve the
> status quo of mips-*-* being big-endian by default and
> mipsel-*-* being little-endian by default, there should be no
> major obstacles to merge those in.
>
For now, two MIPS changes in gnu-user.h and unwind-dw2-fde-dip.c can be
posted for comment.
(I didn't tested this patch, though.)
After starting to build toolchains for Android with Bionic, we may find new
files to
patch. Ex: Comment out getpagesize() for bionic.
Any comment? Thanks a lot!
Regards,
Chao-ying
Index: gcc/gcc/config/mips/gnu-user.h
===
--- gcc.orig/gcc/config/mips/gnu-user.h 2012-04-03 17:39:50.0 -0700
+++ gcc/gcc/config/mips/gnu-user.h 2012-04-04 14:31:50.804236000 -0700
@@ -45,8 +45,8 @@ along with GCC; see the file COPYING3.
/* A standard GNU/Linux mapping. On most targets, it is included in
CC1_SPEC itself by config/linux.h, but mips.h overrides CC1_SPEC
and provides this hook instead. */
-#undef SUBTARGET_CC1_SPEC
-#define SUBTARGET_CC1_SPEC "%{profile:-p}"
+#undef GNU_USER_SUBTARGET_CC1_SPEC
+#define GNU_USER_SUBTARGET_CC1_SPEC "%{profile:-p}"
/* -G is incompatible with -KPIC which is the default, so only allow objects
in the small data section if the user explicitly asks for it. */
@@ -54,8 +54,8 @@ along with GCC; see the file COPYING3.
#define MIPS_DEFAULT_GVALUE 0
/* Borrowed from sparc/linux.h */
-#undef LINK_SPEC
-#define LINK_SPEC \
+#undef GNU_USER_TARGET_LINK_SPEC
+#define GNU_USER_TARGET_LINK_SPEC \
"%(endian_spec) \
%{shared:-shared} \
%{!shared: \
@@ -89,8 +89,8 @@ along with GCC; see the file COPYING3.
#undef ASM_OUTPUT_REG_PUSH
#undef ASM_OUTPUT_REG_POP
-#undef LIB_SPEC
-#define LIB_SPEC "\
+#undef GNU_USER_TARGET_LIB_SPEC
+#define GNU_USER_TARGET_LIB_SPEC "\
%{pthread:-lpthread} \
%{shared:-lc} \
%{!shared: \
@@ -133,7 +133,34 @@ extern const char *host_detect_local_cpu
LINUX_DRIVER_SELF_SPECS
/* Similar to standard Linux, but adding -ffast-math support. */
-#undef ENDFILE_SPEC
-#define ENDFILE_SPEC \
+#undef GNU_USER_TARGET_ENDFILE_SPEC
+#define GNN_USER_TARGET_ENDFILE_SPEC \
"%{Ofast|ffast-math|funsafe-math-optimizations:crtfastmath.o%s} \
%{shared|pie:crtendS.o%s;:crtend.o%s} crtn.o%s"
+
+#undef LINK_SPEC
+#define LINK_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LINK_SPEC, \
+ GNU_USER_TARGET_LINK_SPEC " " ANDROID_LINK_SPEC)
+
+#undef SUBTARGET_CC1_SPEC
+#define SUBTARGET_CC1_SPEC \
+ LINUX_OR_ANDROID_CC (GNU_USER_SUBTARGET_CC1_SPEC,\
+ GNU_USER_SUBTARGET_CC1_SPEC " " ANDROID_CC1_SPEC)
+
+#undef CC1PLUS_SPEC
+#define CC1PLUS_SPEC \
+ LINUX_OR_ANDROID_CC ("", ANDROID_CC1PLUS_SPEC)
+
+#undef LIB_SPEC
+#define LIB_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_LIB_SPEC, \
+ GNU_USER_TARGET_LIB_SPEC " " ANDROID_LIB_SPEC)
+
+#undef STARTFILE_SPEC
+#define STARTFILE_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_STARTFILE_SPEC, ANDROID_STARTFILE_SPEC)
+
+#undef ENDFILE_SPEC
+#define ENDFILE_SPEC \
+ LINUX_OR_ANDROID_LD (GNU_USER_TARGET_ENDFILE_SPEC, ANDROID_ENDFILE_SPEC)
Index: gcc/libgcc/unwind-dw2-fde-dip.c
===
--- gcc.orig/libgcc/unwind-dw2-fde-dip.c2012-04-03 17:07:28.0
-0700
+++ gcc/libgcc/unwind-dw2-fde-dip.c 2012-04-04 14:51:01.338074000 -0700
@@ -48,8 +48,9 @@
#include "gthr.h"
#if !defined(inhibit_libc) && defined(HAVE_LD_EH_FRAME_HDR) \
-&& (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \
- || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG)))
+&& ((defined(__BIONIC__) && (defined(mips) || defined(__mips__))) \
+|| (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ > 2) \
+ || (__GLIBC__ == 2 && __GLIBC_MINOR__ == 2 && defined(DT_CONFIG
# define USE_PT_GNU_EH_FRAME
#endif
Caller save mode on MIPS
Hi All,
From testing, I found out that the whole width of a MIPS
integer/floating-point register
is saved and restored around a call. This may hurt the performance.
Ex:
fu@debian6:/disk/fu/dev/test$ cat add2.c
void test2(float);
float test(float a, float b)
{
test2(a*b);
return a;
}
fu@debian6:/disk/fu/dev/test$ gcc -S -O2 add2.c -mips64r2 -mabi=n32
(# Or )
fu@debian6:/disk/fu/dev/test$ gcc -S -O2 add2.c -mips32r2 -mfp64
fu@debian6:/disk/fu/dev/test$ grep f0 add2.s
mov.s $f0,$f12 <
sdc1$f0,24($sp) <
ldc1$f0,24($sp) <
The 64-bit $f0 is saved and restored via sdc1 and ldc1. However, using lwc1
and swc1 should be ok and faster.
From http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01480.html,
the patch defines HARD_REGNO_CALLER_SAVE_MODE to return proper mode for i386.
For MIPS, we may have:
Ex:
#define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) \
((MODE) == VOIDmode ? choose_hard_reg_mode ((REGNO), (NREGS), false) \
: (MODE))
Any feedback about adding HARD_REGNO_CALLER_SAVE_MODE to MIPS? Thanks!
Regards,
Chao-ying
RE: Caller save mode on MIPS
Richard Sandiford [mailto:rdsandif...@googlemail.com] wrote: > > > From http://gcc.gnu.org/ml/gcc-patches/2001-02/msg01480.html, > > the patch defines HARD_REGNO_CALLER_SAVE_MODE to return > proper mode for i386. > > For MIPS, we may have: > > Ex: > > #define HARD_REGNO_CALLER_SAVE_MODE(REGNO, NREGS, MODE) > \ > >((MODE) == VOIDmode ? choose_hard_reg_mode ((REGNO), > (NREGS), false) \ > >: (MODE)) > > > > Any feedback about adding HARD_REGNO_CALLER_SAVE_MODE to > MIPS? Thanks! > > Sounds like a good idea. > > Richard > I will run regression tests and post a patch later. Thanks a lot! Regards, Chao-ying
RE: Updating an operand in RTL for a builtin function
> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of > Dave Korn > Sent: Friday, May 11, 2007 11:32 AM > To: 'Paul Brook'; gcc@gcc.gnu.org > Cc: 'Mohamed Shafi'; 'Andrew Haley' > Subject: RE: Updating an operand in RTL for a builtin function > > > On 11 May 2007 19:27, Paul Brook wrote: > > >>> > result = __macf(operand1, operand2, operand3); > > >>> > } > >>> > > >>> > Requirement : I need the value of operand3 and result > to be same > > >>> after calling the builtin. > But this is not happening. > >>> > >>> What do you mean, exactly? C only has call by value, and gcc's > >>> builtins can only return one value. Builtins don't change their > >>> arguments. If you want to update one of the arguments > you'll have to > >>> pass a pointer to the builtin. > >> > >> After the builtin i want to have the following operations > also to carried > >> out operand3 = result ; > > > > Why do you want this to happen? > > I think what he means is he wants operand 3 and operand > zero to be placed in > the same register, hence the "0" constraint. As to quite why it's not > working, I don't know. A very similar pattern, only with > "=&" modifiers on > operand zero, works fine for me under 3.4.4. > > > cheers, > DaveK > -- > Can't think of a witty .sigline today > > > >>> > result = __macf(operand1, operand2, operand3); > Since operand3 is passed by value, operand3 should not be changed for the above code. Could you re-write your code as this: "operand3 = __macf(operand1, operand2, operand3);" ? Then, operand3 will be updated. Regards, Chaoy-ing
RE: Fixed-point branch?
> -Original Message- > From: Mark Mitchell [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 31, 2007 9:05 AM > To: Joseph S. Myers > Cc: Fu, Chao-Ying; Richard Henderson; GCC > Subject: Re: Fixed-point branch? > > > Joseph S. Myers wrote: > > > I haven't examined it. When the branch maintainers > consider it ready to > > merge I hope a proposal along the lines of the DFP one > > <http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html> will be > posted (see also > > subsequent discussion in that thread, and on the submitted patches). > > I would like to avoid the situation in which Chao-Ying et. > al. work hard > to come up with a plan, factor the patches, etc., and then we decide > that the code is not going to be ready for 4.3. I had > originally pushed > this work back to 4.4, but as 4.3's been delayed, perhaps there's an > opportunity for it in 4.3. If, however, the work isn't > ready, then I'd > rather not take up a lot of Chao-Ying's time now; instead, we can just > wait for 4.4 to get closer. > > At the same time, of course, there's not much point in you > investing in > looking at the branch if Chao-Ying doesn't think it's ready. > > So, let's do this: > > 1. Chao-Ying, would you please work on any remaining issues that you > feel need resolution. Then, post your merge plan, ala DFP. Yes. We will work on remaining issues and post our merge plan. > > 2. Joseph, at that point, would you please invest a a little > bit of time > (a couple of hours) to look at the branch, and provide some feedback? > Please provide comments to Chao-Ying, and also please let me know > whether you think the work is nearly ready for inclusion? Maybe you could first check if new machine modes, new TREE structures (a saturating bit, fixed-point type, fixed-point constant), new RTL structures (fixed-point constant and operators) are ok. Thanks a lot! Regards, Chao-ying
RE: Fixed-point branch?
Mark Mitchell wrote: > > I attached a diff file for 14 files of the new structures > > and documents. You and other maintainers are welcome to > > check it. Thanks a lot! > > Thank you for posting this. > > Things about which I am clueless: > > What is the difference between a _Fract type and an _Accum type? I'm > gathering that _Fract types have no integer part, i.e., they always > represent a number between (-1,1), whereas _Accum types > contain both an > integer and a fractional part. Is there any other difference? No other differences. For _Fract and _Accum, there are signed and unsigned types. The unsigned _Fract and _Accum types are always >= 0. > > Substantive issues: > > + unsigned saturating_flag : 1; /* FIXME. This new flag > increases the > size of > +tree_common by a full word. */ > > We need to fix that, if it's true. Grab a bit out of > tree_base::spare, > if need be. Yes. Will get one spare bit for saturating_flag. > > + /* Fixed-point types. */ > + if (targetm.fixed_point_supported_p ()) > > I thought there was an emulation library for fixed-point operations? > So, why would this be supported only on some targets? Is there a harm > in supporting it everywhere? If there is, should it be enabled > per-target, or via a configure-time option? Right now, the fixed-point support is a configure-time option. Each target can decide to support it or not. I think there is no harm to enable for every target. But, each target needs to modify tm.h tm.c tm-modes.def to set or change some target macros. > > I don't see any constant-folding code for fixed-point; is > there no need > for that? Is it somewhere else in the codebase? I will post a diff file that has everything including constant-folding code soon. > > Stylistic points: > > Every function needs a comment saying what it does, what > every argument > is, and what the return value is. You have some new > functions that are > missing comments. Ok. Will fix it. > > + fixed-point <- real, > > Please write as "real to fixed point" to avoid ambiguity with > the errors. Ok. Will fix it. > > +DEF_RTL_EXPR(FIXED_ALL, "fixed_all", "e", RTX_UNARY) > > Why FIXED_ALL? That doesn't seem mnemonic. It's hard to pick up a name. Maybe we will change it to the following as Nigel suggested. /* Conversions involving fractional fixed point types without saturation, including: fractional to fractional (of different precision), signed integer to fractional, fractional to signed integer, floating point to fractional, fractional to floating point. */ DEF_RTL_EXPR(FRACT_CONVERT, "fract_convert", "e", RTX_UNARY) > > > + sat_short_fract_type_node = > make_sat_signed_fract_type (SHORT_FRACT_TYPE_SIZE); > > + sat_fract_type_node = make_sat_signed_fract_type > (FRACT_TYPE_SIZE); > > + sat_long_fract_type_node = > make_sat_signed_fract_type (LONG_FRACT_TYPE_SIZE); > > + sat_long_long_fract_type_node = > make_sat_signed_fract_type (LONG_LONG_FRACT_TYPE_SIZE); > > Can we macroize some of this goo? There are several places > in the patch > where you have very long sequences of types, modes, etc. I would hope > that by naming things consistently, we might be able to compact this a > lot, and reduce the chance that we've got something wrong in just one > place. Like: > > #define MAKE_FIXED_TYPE_NODE(KIND, WIDTH, SAT) \ > set_##WIDTH_##KIND_type_node = make_##SAT_... > > and then: > > #define MAKE_FIXED_TYPE_NODE_FAMILY(KIND) \ > MAKE_FIXED_TYPE_NODE(_short, KIND); \ > MAKE_FIXED_TYPE_NODE(_, KIND); \ > MAKE_FIXED_TYPE_NODE(_long, KIND); \ > MAKE_FIXED_TYPE_NODE(_long_long, KIND); > > and then: > > MAKE_FIXED_TYPE_NODE_FAMILY(sat, fract); > MAKE_FIXED_TYPE_NODE_FAMILY(sat, accum); > > etc. > > That's not right, but you get the idea. :-) Ok. We will try to shorten C code. Thanks! Regards, Chao-ying
[fixed-point] A diff file for all changes
Hi, For those who are interested in looking at all changes for the fixed-point branch, I created a diff file of 147 files. This diff file doesn't have changes requested by Mark. Because the diff file is large, I compressed it and posted it to the GCC wiki page (20070608gcc.diff.gz). http://gcc.gnu.org/wiki/FixedPointArithmetic?action=AttachFile To make the merging process manageable, we will have a plan to merge changes steps by steps to ensure that everything still works after every step. Thanks a lot! Regards, Chao-ying 1. Fixed-point testing: Running /home/fu/dev/gcc4xfp/combined/gcc/testsuite/gcc.dg/fixed-point/fixed-point.exp ... === gcc Summary === # of expected passes997 /home/fu/dev/gcc4xfp/build64/gcc/xgcc version 4.3.0 20070608 (experimental) make[1]: Leaving directory `/home/fu/dev/gcc4xfp/build64/gcc' Running /home/fu/dev/gcc4xfp/combined/gcc/testsuite/gcc.dg/fixed-point/fixed-point.exp ... === gcc Summary === # of expected passes997 /home/fu/dev/gcc4xfp/build32r2/gcc/xgcc version 4.3.0 20070608 (experimental) make[1]: Leaving directory `/home/fu/dev/gcc4xfp/build32r2/gcc' 2. (147 Files) Index: libcpp/include/cpplib.h Index: libcpp/expr.c Index: libgcc/Makefile.in Index: gcc/Makefile.in Index: gcc/ginclude/stdfix.h Index: gcc/alias.c Index: gcc/c-common.c Index: gcc/c-common.h Index: gcc/c-convert.c Index: gcc/c-cppbuiltin.c Index: gcc/c-decl.c Index: gcc/c-lex.c Index: gcc/c-parser.c Index: gcc/c-pretty-print.c Index: gcc/c-tree.h Index: gcc/c-typeck.c Index: gcc/config.in Index: gcc/configure Index: gcc/convert.c Index: gcc/convert.h Index: gcc/configure.ac Index: gcc/cse.c Index: gcc/cselib.c Index: gcc/defaults.h Index: gcc/df-scan.c Index: gcc/double-int.c Index: gcc/doc/c-tree.texi Index: gcc/doc/extend.texi Index: gcc/doc/install.texi Index: gcc/doc/md.texi Index: gcc/doc/rtl.texi Index: gcc/doc/tm.texi Index: gcc/dwarf2out.c Index: gcc/emit-rtl.c Index: gcc/expmed.c Index: gcc/expr.c Index: gcc/flow.c Index: gcc/final.c Index: gcc/fixed-value.c Index: gcc/fixed-value.h Index: gcc/fold-const.c Index: gcc/gcse.c Index: gcc/genemit.c Index: gcc/gengenrtl.c Index: gcc/gengtype.c Index: gcc/genmodes.c Index: gcc/genopinit.c Index: gcc/gimplify.c Index: gcc/ipa-prop.c Index: gcc/ipa-type-escape.c Index: gcc/local-alloc.c Index: gcc/loop-invariant.c Index: gcc/machmode.def Index: gcc/machmode.h Index: gcc/mode-classes.def Index: gcc/optabs.c Index: gcc/optabs.h Index: gcc/postreload-gcse.c Index: gcc/print-tree.c Index: gcc/regclass.c Index: gcc/recog.c Index: gcc/regrename.c Index: gcc/reload.c Index: gcc/reload1.c Index: gcc/resource.c Index: gcc/rtl.c Index: gcc/rtl.def Index: gcc/rtl.h Index: gcc/rtlanal.c Index: gcc/target-def.h Index: gcc/sched-deps.c Index: gcc/sched-vis.c Index: gcc/simplify-rtx.c Index: gcc/stor-layout.c Index: gcc/target.h Index: gcc/targhooks.c Index: gcc/targhooks.h Index: gcc/tree.c Index: gcc/tree.def Index: gcc/tree.h Index: gcc/tree-browser.c Index: gcc/tree-complex.c Index: gcc/tree-dump.c Index: gcc/tree-gimple.c Index: gcc/tree-inline.c Index: gcc/tree-pretty-print.c Index: gcc/tree-scalar-evolution.c Index: gcc/tree-ssa-loop-im.c Index: gcc/tree-ssa-pre.c Index: gcc/tree-ssa-reassoc.c Index: gcc/tree-vect-generic.c Index: gcc/tree-vect-transform.c Index: gcc/treestruct.def Index: gcc/varasm.c Index: gcc/config/fixed-bit.c Index: gcc/config/fixed-bit.h Index: gcc/config/mips/mips.c Index: gcc/config/mips/mips.h Index: gcc/config/mips/mips.md Index: gcc/config/mips/mips-modes.def Index: gcc/config/mips/mips-fixed.md Index: gcc/testsuite/lib/target-supports.exp Index: gcc/testsuite/gcc.dg/fixed-point/fixed-point.exp Index: gcc/testsuite/gcc.dg/fixed-point/addsub.c Index: gcc/testsuite/gcc.dg/fixed-point/allconv.c Index: gcc/testsuite/gcc.dg/fixed-point/allop.c Index: gcc/testsuite/gcc.dg/fixed-point/allop-const.c Index: gcc/testsuite/gcc.dg/fixed-point/call-by-value.c Index: gcc/testsuite/gcc.dg/fixed-point/cast-bad.c Index: gcc/testsuite/gcc.dg/fixed-point/composite-type.c Index: gcc/testsuite/gcc.dg/fixed-point/const-1.c Index: gcc/testsuite/gcc.dg/fixed-point/constant.c Index: gcc/testsuite/gcc.dg/fixed-point/constants-pedantic.c Index: gcc/testsuite/gcc.dg/fixed-point/convert.c Index: gcc/testsuite/gcc.dg/fixed-point/define.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-c89.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-c99.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-ignored-c99.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-pedantic.c Index: gcc/testsuite/gcc.dg/fixed-point/keywords-reserved.c Index: gcc/testsuite/gcc.dg/fixed-point/modes.c Index: gcc/testsuite/gcc.dg/fixed-point/noassoc.c Index: gcc/testsuite/gcc.dg/fixed-point/types.c Index: gcc/testsuite/gcc.dg/fixed-point/typespec.c Index: gcc/testsuite/gcc.dg/fixed-point/unary.c Index: gcc/testsuite/gcc.dg/fixed-point/binary.c Index: gcc/testsuite/gcc.target/mips/dpaq_sa_l_w.c Index: gcc/testsuite/
[fixed-point] Fixed-point branch merge plan
Hi, As Mark requested, we propose a merge plan for the fixed-point branch as follows. 1. Merge in machine modes to support signed and unsigned fract and accum modes. Handle scalar and vector modes. 2. Merge in fixed-value.h and fixed-value.c to handle fixed-point values. 3. Merge in TREE structures for fixed-point types and constants. 4. Merge in C front-end changes to parse _Sat, _Fract and _Accum. 5. Merge in RTL structures for fixed-point constants and operators. 6. Merge in libcpp to parse fixed-point constants. 7. Merge in changes to support "case" of FIXED_POINT_TYPE, FIXED_CST, and CONST_FIXED in .c and .h files. 8. Merge in the MIPS backend that supports fixed-point instructions. 9. Merge in configure/build system changes for the runtime library. 10. Merge in testsuite (from gcc.dg/fixed-point) that only run when the compiler is configured to enable fixed-point. This plan is similar to the DFP merge plan from this link. http://gcc.gnu.org/ml/gcc/2005-11/msg01128.html Our changes will be active for the mips target and all other targets should not be affected. For each step, we will wait for some days to fix any breakage. Comments are welcome! Thanks a lot! Regards, Chao-ying
RE: Fixed-point branch?
Bernd Schmidt wrote:
> > I attached a diff file for 14 files of the new structures
> > and documents. You and other maintainers are welcome to
> > check it. Thanks a lot!
> >
> > Note: 14 files are =>
> > genmodes.c mode-classes.def machmode.def machmode.h tree.def tree.h
> > tree.c rtl.def rtl.h rtl.c fixed-value.h fixed-value.c
> > doc/extend.texi doc/rtl.texi doc/c-tree.texi doc/md.texi
>
> Random comments..
>
> > + unsigned saturating_flag : 1; /* FIXME. This new flag
> increases the size of
> > + tree_common by a full word. */
>
> Sounds undesirable. We need to look hard for a way to avoid this.
Yes, we can get one of 24 spare bits for this flag. We just fixed this
issue last week.
>
> > +ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */
> > +ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */
> > +ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */
> > +ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */
>
> Lots of predefined types and modes in this patch. What about targets
> with other requirements (the Blackfin has 40 bit (8 + 32)
> accumulators)?
In "bfin-modes.def", we can adjust the DA mode to (s7.32) by using
ADJUST_IBIT(DA, 7)
ADJUST_FBIT(DA, 32)
>
> For vectors, we let the targets define the supported modes. Why do we
> want something else for fractional support?
I am not clear about this question. The new modes (FRACT, UFRACT, ACCUM,
and UACCUM) enables GCC to recognize the formats of the underlying values
to perform constant folding (e.g., + - * /).
To use the DA mode for vector, we can use:
VECTOR_MODE (ACCUM, DA, 2);
>
> > +int
> > +fixed_zerop (tree expr)
> > +{
> > + return TREE_CODE (expr) == FIXED_CST
> > +&& double_int_zero_p (TREE_FIXED_CST (expr).data);
> > +}
>
> Formatting - this needs parentheses. Elsewhere too.
Ok.
>
> > +static tree
> > +make_or_reuse_fract_type (unsigned size, int unsignedp, int satp)
>
> Comments before functions.
Ok. Thanks!
Regards,
Chao-ying
RE: Fixed-point branch?
Bernd Schmidt wrote: > >>> +ACCUM_MODE (HA, 2, 8, 7); /* s8.7 */ > >>> +ACCUM_MODE (SA, 4, 16, 15); /* s16.15 */ > >>> +ACCUM_MODE (DA, 8, 32, 31); /* s32.31 */ > >>> +ACCUM_MODE (TA, 16, 64, 63); /* s64.63 */ > >> Lots of predefined types and modes in this patch. What > about targets > >> with other requirements (the Blackfin has 40 bit (8 + 32) > >> accumulators)? > > > > In "bfin-modes.def", we can adjust the DA mode to (s7.32) by using > > ADJUST_IBIT(DA, 7) > > ADJUST_FBIT(DA, 32) > > > >> For vectors, we let the targets define the supported > modes. Why do we > >> want something else for fractional support? > > > > I am not clear about this question. The new modes > (FRACT, UFRACT, ACCUM, > > and UACCUM) enables GCC to recognize the formats of the > underlying values > > to perform constant folding (e.g., + - * /). > > To use the DA mode for vector, we can use: > > VECTOR_MODE (ACCUM, DA, 2); > > No, I was trying to make an analogy of how ports explicitly > define the > modes their hardware supports, e.g. for arm: > > /* Vector modes. */ > VECTOR_MODES (INT, 4);/*V4QI V2HI */ > VECTOR_MODES (INT, 8);/* V8QI V4HI V2SI */ > VECTOR_MODES (INT, 16); /* V16QI V8HI V4SI V2DI */ > VECTOR_MODES (FLOAT, 8); /*V4HF V2SF */ > VECTOR_MODES (FLOAT, 16); /* V8HF V4SF V2DF */ > > I'm wondering whether it's a good idea to have a lot of pre-defined > fractional modes and types that may or may not match the target > hardware. Not saying it's necessarily wrong; I'm just interested to > hear why you chose to do it this way. (I also just noticed > that things > like SHORT_ACCUM_TYPE_SIZE are used but apparently not defined in the > patch - does it actually compile?) > Ok. I got it. Maybe we treat fixed-point modes as the first class modes like other scalar modes (integer, floating, etc.), so we pre-define them. We can argue that how about making machine modes (ex: floating-point, decimal floating-point) not pre-defined, similar to vector modes. I think, the default fixed-point formats are the efficient ones for 32-bit/64-bit processors (with or without hardware supports). One of the goals for the fixed-point extension is that all targets in GCC will enable the extension, so efficient formats may be set by default. We have all FRACT and ACCUM sizes in defaults.h. Thanks! #ifndef SHORT_FRACT_TYPE_SIZE #define SHORT_FRACT_TYPE_SIZE BITS_PER_UNIT #endif #ifndef FRACT_TYPE_SIZE #define FRACT_TYPE_SIZE (BITS_PER_UNIT * 2) #endif #ifndef LONG_FRACT_TYPE_SIZE #define LONG_FRACT_TYPE_SIZE (BITS_PER_UNIT * 4) #endif #ifndef LONG_LONG_FRACT_TYPE_SIZE #define LONG_LONG_FRACT_TYPE_SIZE (BITS_PER_UNIT * 8) #endif #ifndef SHORT_ACCUM_TYPE_SIZE #define SHORT_ACCUM_TYPE_SIZE (SHORT_FRACT_TYPE_SIZE * 2) #endif #ifndef ACCUM_TYPE_SIZE #define ACCUM_TYPE_SIZE (FRACT_TYPE_SIZE * 2) #endif #ifndef LONG_ACCUM_TYPE_SIZE #define LONG_ACCUM_TYPE_SIZE (LONG_FRACT_TYPE_SIZE * 2) #endif #ifndef LONG_LONG_ACCUM_TYPE_SIZE #define LONG_LONG_ACCUM_TYPE_SIZE (LONG_LONG_FRACT_TYPE_SIZE * 2) #endif Regards, Chao-ying
[MIPS] One test failed
Hi,
I got one test that failed by using the mainline GCC
on the target of mipsisa32r2-elf.
The handling of stack pointer or frame pointer may be broken.
Thanks!
Ex:
# mipsisa32r2-elf-gcc -o bug126 -Tidt32.ld bug126.c
# mipsisa32r2-elf-run bug126
mips-core: 4 byte read to unmapped address 0x4 at 0x80020348
program stopped with signal 10.
# cat bug126.c
int check_var (int z, ...)
{
}
int main ()
{
check_var (2);
return 0;
}
(big126.s)
check_var:
.frame $fp,80,$31
.mask 0x4000,-4
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-80
sw $fp,76($sp) <--
move$fp,$sp
sw $5,52($fp)
sw $6,56($fp)
sw $7,60($fp)
sw $8,64($fp)
sw $9,68($fp)
sw $10,72($fp)
sw $11,76($fp) <-- Data is written again.
sdc1$f12,16($fp)
sdc1$f14,24($fp)
sdc1$f16,32($fp)
sdc1$f18,40($fp)
sw $4,0($fp)
move$sp,$fp
lw $fp,76($sp) <-- FP is wrong.
addiu $sp,$sp,80
j $31
nop
.setmacro
.setreorder
.endcheck_var
.size check_var, .-check_var
.align 2
.globl main
.entmain
main:
.frame $fp,8,$31
.mask 0xc000,-4
.fmask 0x,0
.setnoreorder
.setnomacro
addiu $sp,$sp,-8
sw $31,4($sp)
sw $fp,0($sp)
move$fp,$sp
li $4,2
jal check_var
nop
move$2,$0
move$sp,$fp <--- SP is wrong.
lw $31,4($sp) <-- FAIL
lw $fp,0($sp)
addiu $sp,$sp,8
j $31
nop
Regards,
Chao-ying
RE: Bootstrap failure on i386-pc-linux-gnu
FX Coudert wrote: > > My automated nightly build failed to bootstrap this evening on i386- > pc-linux-gnu. This is for trunk rev. 127311, and the error is: > > > /home/fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/xgcc -B/home/ > > fx/gfortran_nightbuild/ibin-20070809/./prev-gcc/ -B/home/fx/ > > gfortran_nightbuild/irun-20070809/i386-pc-linux-gnu/bin/ -c -g - > > O2 -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings - > > Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition - > > Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic- > > macros -Wno-overlength-strings -Werror- > > DHAVE_CONFIG_H -I. -I. -I/home/fx/gfortran_nightbuild/trunk/gcc -I/ > > home/fx/gfortran_nightbuild/trunk/gcc/. -I/home/fx/ > > gfortran_nightbuild/trunk/gcc/../include -I/home/fx/ > > gfortran_nightbuild/trunk/gcc/../libcpp/include -I/home/fx/ > > gfortran_nightbuild/software/include -I/home/fx/ > > gfortran_nightbuild/trunk/gcc/../libdecnumber -I/home/fx/ > > gfortran_nightbuild/trunk/gcc/../libdecnumber/bid -I../ > > libdecnumber/home/fx/gfortran_nightbuild/trunk/gcc/tree.c -o > > tree.o > > cc1: warnings being treated as errors > > /home/fx/gfortran_nightbuild/trunk/gcc/tree.c: In function > > 'initializer_zerop': > > /home/fx/gfortran_nightbuild/trunk/gcc/tree.c:7694: error: passing > > argument 1 of 'fixed_zerop' discards qualifiers from > pointer target > > type > > make[3]: *** [tree.o] Error 1 > > make[3]: Leaving directory `/home/fx/gfortran_nightbuild/ > > ibin-20070809/gcc' > > make[2]: *** [all-stage2-gcc] Error 2 > > I filed PR 33031 for this issue. > > Thanks, > FX > Thanks a lot! I think this has been fixed by Michael Matz. 2007-08-09 Michael Matz <[EMAIL PROTECTED]> * tree.h (fixed_zerop): Declare as taking a const_tree. * tree.c (fixed_zerop): Take a const_tree. Regards, Chao-ying
RE: Bootstrap failure with --enable-checking=all,rtl
Hi, Sorry about the breakage. I checked in the change (rtl.h) to fix this issue. SendingChangeLog Sendingrtl.h Transmitting file data .. Committed revision 127825. Thanks a lot! Regards, Chao-ying -Original Message- From: Andreas Jaeger [mailto:[EMAIL PROTECTED] Sent: Sunday, August 26, 2007 6:28 AM To: gcc@gcc.gnu.org; Fu, Chao-Ying Subject: Bootstrap failure with --enable-checking=all,rtl I get a bootstrap error on Linux/x86-64 with current svn: /abuild/aj/gcc/./prev-gcc/xgcc -B/abuild/aj/gcc/./prev-gcc/ -B/opt/gcc/4.3-devel/x86_64-suse-linux-gnu/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I/cvs/gcc-svn/trunk/gcc -I/cvs/gcc-svn/trunk/gcc/. -I/cvs/gcc-svn/trunk/gcc/../include -I/cvs/gcc-svn/trunk/gcc/../libcpp/include -I/cvs/gcc-svn/trunk/gcc/../libdecnumber -I/cvs/gcc-svn/trunk/gcc/../libdecnumber/bid -I../libdecnumber /cvs/gcc-svn/trunk/gcc/cse.c -o cse.o cc1: warnings being treated as errors /cvs/gcc-svn/trunk/gcc/cse.c: In function 'hash_rtx': /cvs/gcc-svn/trunk/gcc/cse.c:2165: error: initialization discards qualifiers from pointer target type make[3]: *** [cse.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcj-dbtool.pod fsf-funding.pod jcf-dump.pod jv-convert.pod grmic.pod gcov.pod gcj.pod gfdl.pod gpl.pod cpp.pod gij.pod gc-analyze.pod gfortran.pod gcc.pod make[3]: Leaving directory `/abuild-old/aj/gcc/gcc' make[2]: *** [all-stage2-gcc] Error 2 this seems to have been introduced by: 2007-08-22 Chao-ying Fu <[EMAIL PROTECTED]> [...] * cse.c (hash_rtx): Support CONST_FIXED. Chao-ying, could you fix this, please? Andreas -- Andreas Jaeger, Director Platform/openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
RE: Error in c-lex.c
Revital1 Eres wrote: > > I get the following error running trunk r127993 with > --enable-checking=assert on ppc64: > > gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall > -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition > -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc > -I../../gcc/gcc/. -I../../gcc/gcc/../include > -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber > -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber > ../../gcc/gcc/c-lex.c -o c-lex.o > ../../gcc/gcc/c-lex.c: In function גinterpret_floatג: > ../../gcc/gcc/c-lex.c:645: error: גCPP_N_FRACTג undeclared > (first use in > this function) > ../../gcc/gcc/c-lex.c:645: error: (Each undeclared identifier > is reported > only once > ../../gcc/gcc/c-lex.c:645: error: for each function it appears in.) > ../../gcc/gcc/c-lex.c:645: error: גCPP_N_ACCUMג undeclared > (first use in > this function) > ../../gcc/gcc/c-lex.c: In function גinterpret_fixedג: > ../../gcc/gcc/c-lex.c:753: error: גCPP_N_FRACTג undeclared > (first use in > this function) > make[3]: *** [c-lex.o] Error 1 > > Thanks, > Revital > We need to update gcc/libcpp in order to get these definitions. Thanks a lot! Regards, Chao-ying
RE: GCC 4.3.0 Status Report (2007-09-04)
Manuel López-Ibáñez wrote: > > On 05/09/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: > > Summary > > === > > > > We are closing in on Stage 3, previously announced for > September 10th. > > At this point, I'm not aware of any reason to delay that date. Are > > there any Stage 2 patches that people don't think will be > submitted by > > that point? > > > > Are there Stage 1 or Stage 2 patches in need of review? > I'll do my best > > to either (a) convince someone to review them, or (b) > review them myself. > > > > The patches to make the new -Wconversion work with decimal float types > are still pending review. > http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01356.html > > Unfortunately, even if I could skip sleep for one night to get some > extra time, I won't have the means needed to test them, update them to > current trunk or commit them before Sep 10th. Perhaps in two or three > weeks I could... > > By the way, have the patches for FixedPointArithmetic added > Wconversion support? I guess that will make the patches above to not > apply cleanly anymore. Not yet. After I get the remaining patches (7, 8, 9, 10) checked in, I will see how much work is needed to support Wconversion for fixed-point types. Thanks! Regards, Chao-ying
