Re: Cannot build gcc-4.1.2 on cygwin: /bin/sh: kinds.h: No such file or directory
2007/2/22, Christian Joensson <[EMAIL PROTECTED]>: well, I ended up reinstalling gmp, libgmp-devel, libgmp3, mpfr, libmpfr-devel, libmpfr0 (which I don't think is nessecary) and libmpfr1. now, its testsuite is being run thanks brian and brooks for you help. here's the test results http://gcc.gnu.org/ml/gcc-testresults/2007-02/msg00886.html Does it look ok with you guys? -- Cheers, /ChJ
Re: warning: source missing a mode?
Markus Franke wrote:
---snip---
Processing file 2120-2.c
2120-2.c: In function 'foo':
2120-2.c:13: error: unrecognizable insn:
(call_insn 14 13 15 1 (parallel [
(set:SI (reg:SI 1 r1)
(call (mem:QI (symbol_ref:SI ("odd") [flags 0x3]
) [0 S1 A8])
(const_int 8 [0x8])))
(clobber (reg:SI 31 r31))
]) -1 (nil)
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil))
(nil))
As Ian already said, there must be someone who is issuing the SI-less
call (btw. I would just leave the SI, and live with the warning. Almost
all backends use a modeless call).
(define_insn "call_val_internal_return_r1"
With the name of this function, you probably have somewhere a
define_expand for a call, and my guess would be that they issue the
modeless call (do a s/(call /(call:SI /g).
Florian
I need some advice for x86_64-pc-mingw32 va_list calling convention (in i386.c)
Hi, I am currently on a mingw32 port for x86_64. It is operatable and I am allready able to generate the crt-stuff and have some needed import-libraries. Executables are linkable and executeable, but wildcard methods are leading to wrong execution, as found out. I detected, that the MS-ABI does not support SSE or MMX argument passing (as gcc does for x86_64). Therefore I search some advice about the enforcement of passing (sse,mmx) registers passing via the standard integer registers (for MS they are ecx,edx,r9) and via stack. The current patch for supporting this x86_64-targer I allready posted to gcc-patch. I would be very pleased, if somebody could give me a hint about the patch needed. Thank you very much, i.A. Kai Tietz
build Error
i am trying to build gcc-3.4.6 for that i untar gcc-ada-3.4.6 and gcc-core-3.4.6 in directory "/source" and my build directory is not subdirectory of source directory i got error like this:- gcc -c -g -O2 -gnatpg -gnata -I- -I. -Iada -I../../source/gcc-3.4.6/gcc/ada ../../source/gcc-3.4.6/gcc/ada/ali.adb -o ada/ali.o fatal error: system.ads is incorrectly formatted missing line for parameter: Preallocated_Stacks compilation abandoned make[1]: *** [ada/ali.o] Error 1 make[1]: Leaving directory `/home/sameer/GCC_SOURCE_CODE/GCC-ADA/GCC-3.4.6/build/gcc' make: *** [all-gcc] Error 2
Comparison of Itanium gcc 4.1 and 4.2 on Spec2000
Here is the comparison of 4.1 branch and 4.2 branch. In brief, 4.2
has 0.47% better performance in SPECInt2000 and 2.2% better
performance in SPECFP2000.
As I remeber this increase in SPECFP performance is as mostly from
implementation of Itanium speculation support for scheduling by ISP
RAS (many thanks for implementing that). Generally speaking, the
speculation insns isn inserted when we can not say something about
aliasing (so it compensates too conseravtive aliasing).
The code size (text segment) is 0.3% and 1.2% bigger corresponding
on SPECINT2000 and SPECFP2000 for 4.2. It is not important for
itanium because it is the least sensitive processor for code locality
(btw intel compiler generates up 2 times bigger code).
The 4.2 compiler is 19% slower on compilation SPECINT2000 (both
versions of compiler compiled with --enable-checking=release). I
don't know why. I have no time for the investiagation.
Itanium 1.6Ghz. Option is -O2
base: 4.1
peak: 4.2
Estimated Estimated
Base Base Base Peak Peak Peak
BenchmarksRef Time Run Time RatioRef Time Run Time Ratio
164.gzip 1400 207 676* 1400 194 720*
175.vpr 1400 156 900* 1400 156 898*
176.gcc 1100 91.9 1197* 1100 92.3 1191*
181.mcf 1800 1701057* 1800 1651093*
186.crafty1000 106 947* 1000 108 927*
197.parser1800 245 734* 1800 245 734*
252.eon 1300 166 781* 1300 173 751*
253.perlbmk 1800 199 903* 1800 207 872*
254.gap 1100 214 513* 1100 205 537*
255.vortex1900 1851027* 1900 1891006*
256.bzip2 1500 200 749* 1500 192 783*
300.twolf 3000 2721102* 3000 2731098*
Est. SPECint_base2000 860
Est. SPECint2000 864
Estimated Estimated
Base Base Base Peak Peak Peak
BenchmarksRef Time Run Time RatioRef Time Run Time Ratio
168.wupwise 1600 358 448* 1600 347 462*
171.swim 3100 577 538* 3100 572 542*
172.mgrid 1800 595 303* 1800 659 273*
173.applu 2100 534 393* 2100 538 390*
177.mesa 1400 173 811* 1400 173 809*
178.galgel2900 456 636* 2900 340 853*
179.art 2600 128 2025* 2600 122 2125*
183.equake1300 387 336* 1300 384 339*
187.facerec 1900 427 445* 1900 432 439*
188.ammp 2200 305 722* 2200 272 808*
189.lucas 2000 252 795* 2000 252 794*
191.fma3d 2100 788 266* 2100 799 263*
200.sixtrack 1100 313 352* 1100 329 334*
301.apsi 2600 486 535* 2600 486 535*
Est. SPECfp_base2000 527
Est. SPECfp2000 539
Code size
CINT2000-
-3.813% 91125 87650 164.gzip
-0.864% 295303 292751 175.vpr
2.671%32054703291094 176.gcc
0.509% 25148 25276 181.mcf
-0.377% 407562 406026 186.crafty
-0.529% 238765 237501 197.parser
3.022% 929950 958057 252.eon
1.614%13916921414148 253.perlbmk
-0.599%11506301143742 254.gap
1.610%11635561182292 255.vortex
0.227% 69658 69816 256.bzip2
0.672% 494901 498229 300.twolf
Average = 0.27621%
CFP2000-
6.248% 51217 54417 168.wupwise
1.425% 20770 21066 171.swim
6.089% 24437 25925 172.mgrid
-3.501% 108097 104313 173.applu
0.087%12544821255570 177.mesa
-0.684% 364988 362491 178.galgel
-0.793% 35299 35019 179.art
1.827% 43781 44581 183.equake
0.359% 119370 119798 187.facerec
0.202% 376484 377244 188.ammp
-0.612% 86159 85632 189.lucas
2.302%23231322376611 191.fma3d
0.943%20525472071911 200
Re: Floating point insn dependency - GCC 4.1.1
"Rohit Arul Raj" <[EMAIL PROTECTED]> writes: > I am adding floating point support to GCC 4.1.1 for a private target. > > My machine can issue > (1) Two instructions, [one integer insns (16 bit) + one floating point > insn (16 bit) ]or > (2) one 32 bit integer insn. > > For case (1) , Since both instructions are executed parallely, there > is no dependecy check between them. > > for e.g. if the generated insn is > mov 5, A0 > movf A0, F0 > > Since both these instructions are executed parallely, the value of F0 > is not 5 but it takes the previous value of A0. > > 1. Is there a way to check for dependency b/w this two instructions. > 2. Any existing backend that has this type of design. gcc currently does a relatively crummy job of handling this type of VLIW architecture. You can describe the dependencies in the scheduler, but the scheduler won't insert any required nops for you. The usual approach is walk through the insn chain in the MD reorg pass and insert nops at that time. For example, look at mips_reorg in config/mips/mips.c. I've also done it in FINAL_PRESCAN_INSN. Ian
Fold and integer types with sub-ranges
Currently for example in fold_sign_changed_comparison we produce integer constants that are not inside the range of its type values denoted by [TYPE_MIN_VALUE (t), TYPE_MAX_VALUE (t)]. For example consider a type with range [10, 20] and the comparison created by the Ada frontend: if ((signed char)t == -128) t being of that type [10, 20] with TYPE_PRECISION 8, like the constant -128. So fold_sign_changed_comparison comes along and decides to strip the conversion and convert the constant to type T which looks like unit size user align 8 symtab 0 alias set 4 canonical type 0x2b8156099c00 precision 8 min max RM size > readonly sizes-gimplified public unsigned QI size unit size user align 8 symtab 0 alias set 4 canonical type 0x2b8156099f00 precision 8 min max RM size constant invariant 5>> (note it's unsigned!) So the new constant gets produced using force_fit_type_double with the above (unsigned) type and the comparison now prints as if (t == 128) and the new constant 128 now being out of range of its type: constant invariant 128> (see the min/max values of that type above). What do we want to do about that? Do we want to do anything about it? If we don't want to do anything about it, why care about an exact TREE_TYPE of integer constants if the only thing that matters is signedness and type precision? Thanks for any hints, Richard.
Re: Fold and integer types with sub-ranges
> Currently for example in fold_sign_changed_comparison we produce > integer constants that are not inside the range of its type values > denoted by [TYPE_MIN_VALUE (t), TYPE_MAX_VALUE (t)]. For example > consider a type with range [10, 20] and the comparison created by > the Ada frontend: > > if ((signed char)t == -128) > > t being of that type [10, 20] with TYPE_PRECISION 8, like the constant > -128. So fold_sign_changed_comparison comes along and decides to strip > the conversion and convert the constant to type T which looks like ... > What do we want to do about that? Do we want to do anything about it? > If we don't want to do anything about it, why care about an exact > TREE_TYPE of integer constants if the only thing that matters is > signedness and type precision? I don't think gcc should be converting anything to a type like t's unless it can prove that the thing it's converting is in the range of t's type. So it presumably should try to prove: (1) that -128 is not in the range of t's type; if it's not, then fold the comparison to false; otherwise (2) try to prove that -128 is in the range of t's type; if so, convert it. Otherwise do nothing. That said, this whole thing is a can of worms. Suppose the compiler wants to calculate t+1. Of course you do something like this: int_const_binop (PLUS_EXPR, t, build_int_cst (TREE_TYPE (t), 1), 0); But if 1 is not in the type of t, you just created an invalid value! Personally I think the right thing to do is to eliminate these types altogether somewhere early on, replacing them with their base types (which don't have funky ranges), inserting appropriate ASSERT_EXPRs instead. Probably types like t should never be seen outside the Ada f-e at all. Ciao, Duncan.
Re: Floating point insn dependency - GCC 4.1.1
> > 1. Is there a way to check for dependency b/w this two instructions. > > 2. Any existing backend that has this type of design. > > gcc currently does a relatively crummy job of handling this type of > VLIW architecture. You can describe the dependencies in the > scheduler, but the scheduler won't insert any required nops for you. > The usual approach is walk through the insn chain in the MD reorg pass > and insert nops at that time. For example, look at mips_reorg in > config/mips/mips.c. I've also done it in FINAL_PRESCAN_INSN. Given you only have limited dual-issue, could the delay slot mechanisms be used for this? Paul
Re: Floating point insn dependency - GCC 4.1.1
Paul Brook <[EMAIL PROTECTED]> writes: > > > 1. Is there a way to check for dependency b/w this two instructions. > > > 2. Any existing backend that has this type of design. > > > > gcc currently does a relatively crummy job of handling this type of > > VLIW architecture. You can describe the dependencies in the > > scheduler, but the scheduler won't insert any required nops for you. > > The usual approach is walk through the insn chain in the MD reorg pass > > and insert nops at that time. For example, look at mips_reorg in > > config/mips/mips.c. I've also done it in FINAL_PRESCAN_INSN. > > Given you only have limited dual-issue, could the delay slot mechanisms be > used for this? Sure, I've done that too, but you still have to insert the nops manually. That is what mips.c is doing. The delay slot mechanisms will fill in an insn if there is one, but they won't fill in a nop if there isn't an insn. Basically sched2 and subsequent passes need an overhaul to support VLIW systems. Ian
Re: Comparison of Itanium gcc 4.1 and 4.2 on Spec2000
Vladimir N. Makarov wrote: > Here is the comparison of 4.1 branch and 4.2 branch. In brief, 4.2 > has 0.47% better performance in SPECInt2000 and 2.2% better > performance in SPECFP2000. Thanks! I assume that is with the aliasing safety patches turned on, i.e., current state of the 4.2 branch? Are you able to try reverting the aliasing patches to see how much of an impact they have on Itanium? It would be interesting to know how that compares with the 4% on IA32. Thanks, -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
Re: Fold and integer types with sub-ranges
On Fri, 23 Feb 2007, Duncan Sands wrote: > > Currently for example in fold_sign_changed_comparison we produce > > integer constants that are not inside the range of its type values > > denoted by [TYPE_MIN_VALUE (t), TYPE_MAX_VALUE (t)]. For example > > consider a type with range [10, 20] and the comparison created by > > the Ada frontend: > > > > if ((signed char)t == -128) > > > > t being of that type [10, 20] with TYPE_PRECISION 8, like the constant > > -128. So fold_sign_changed_comparison comes along and decides to strip > > the conversion and convert the constant to type T which looks like > ... > > What do we want to do about that? Do we want to do anything about it? > > If we don't want to do anything about it, why care about an exact > > TREE_TYPE of integer constants if the only thing that matters is > > signedness and type precision? > > I don't think gcc should be converting anything to a type like t's unless > it can prove that the thing it's converting is in the range of t's type. So > it presumably should try to prove: (1) that -128 is not in the range of > t's type; if it's not, then fold the comparison to false; otherwise (2) try > to prove that -128 is in the range of t's type; if so, convert it. Otherwise > do nothing. > > That said, this whole thing is a can of worms. Suppose the compiler wants to > calculate t+1. Of course you do something like this: > > int_const_binop (PLUS_EXPR, t, build_int_cst (TREE_TYPE (t), 1), 0); > > But if 1 is not in the type of t, you just created an invalid value! Eeek ;) True. Another reason to not force us creating 1s and 0s in such cases but allow simply int_const_binop_int (PLUS_EXPR, t, 1) of course while int_const_binop will truncate the result to its TYPE_PRECISION one still needs to make sure the result fits in t. That is, all the fancy TREE_OVERFLOW stuff only cares about TYPE_PRECISION and never about the types 'true' range via min/max value. > Personally I think the right thing to do is to eliminate these types > altogether somewhere early on, replacing them with their base types > (which don't have funky ranges), inserting appropriate ASSERT_EXPRs > instead. Probably types like t should never be seen outside the Ada > f-e at all. Heh - nice long-term goal ;) Might raise the usual wont-work-for-proper-debug-info complaint though. Richard.
Re: Comparison of Itanium gcc 4.1 and 4.2 on Spec2000
Mark Mitchell wrote: Vladimir N. Makarov wrote: Here is the comparison of 4.1 branch and 4.2 branch. In brief, 4.2 has 0.47% better performance in SPECInt2000 and 2.2% better performance in SPECFP2000. Thanks! I assume that is with the aliasing safety patches turned on, i.e., current state of the 4.2 branch? Are you able to try reverting the aliasing patches to see how much of an impact they have on Itanium? It would be interesting to know how that compares with the 4% on IA32. Yes, that is the current state of 4.1 and 4.2 branches (as of yesterday). I don't think we will see a change with the reverted alaising patches for itanium because conservative aliasing most probably will be compensated by itanium hardware (itanium speculation insn support was added for 4.2).
Re: I need some advice for x86_64-pc-mingw32 va_list calling convention (in i386.c)
Kai Tietz writes: >I detected, that the MS-ABI does not support SSE or MMX argument passing >(as gcc does for x86_64). Therefore I search some advice about the >enforcement of passing (sse,mmx) registers passing via the standard >integer registers (for MS they are ecx,edx,r9) and via stack. I think you may be confused here. You don't pass registers, you pass values. Micrsoft's x64 ABI documents how to pass values with SSE and MMX types: __m128 types, arrays and strings are never passed by immediate value but rather a pointer will be passed to memory allocated by the caller. Structs/unions of size 8, 16, 32, or 64 bits and __m64 will be passed as if they were integers of the same size. Structs/unions other than these sizes will be passed as a pointer to memory allocated by the caller. For these aggregate types passed as a pointer (including __m128), the caller-allocated temporary memory will be 16-byte aligned. Since __m128 types are the equivilent of GCC's 128-bit vector types (SSE), values of this type should be passed by reference. GCC's 64-bit vector types (MMX) should by passed by value using an integer register. This is how SSE and MMX values should be passed regardless of wether the function takes a variable number of arguments or not. Ross Ridge
Re: warning: source missing a mode?
On Thu, Feb 22, 2007 at 11:10:09AM +0100, Markus Franke wrote: > ;; calls that return int in r1 > ;; > (define_insn "call_val_internal_return_r1" > [(parallel [(set (reg:SI 1) > (call (match_operand:QI 0 "sym_ref_mem_operand" "") Why would you have a specific pattern for (reg:SI 1) as the return value? I suggest you look at other ports for guidence here. Normal is something like (define_insn "*call_value_1" [(set (match_operand 0 "" "") (call (mem:QI (match_operand:SI 1 "call_insn_operand" "rsm")) (match_operand:SI 2 "" "")))] ...) where both the return value and the call have no mode specified. r~
Re: ix86_data_alignment: bad defaults?
On Thu, Feb 22, 2007 at 05:03:21PM -0800, Ian Lance Taylor wrote: > > > It is to improve performance of string functions on larger chunks of > > > data. x86-64 specify this, for x86 it is optional. I don't think we > > > should end up warning here - it is done only for static variables where > > > the alignment can be higher than what BIGGEST_ALIGNMENT promise. > > > > Higher than BIGGEST_ALIGNMENT? So, maybe we should rename it > > ALMOST_BIGGEST_ALIGNMENT? I'm confused. > > Yes, BIGGEST_ALIGNMENT is supposed to be the biggest alignment the > compiler will ever use. I thought BIGGEST_ALIGNMENT was the largest alignment that the processor ever requires for any data type. Which is not the same thing, since this is alignment desired for performance. r~
Re: Floating point insn dependency - GCC 4.1.1
On Fri, Feb 23, 2007 at 07:00:01AM -0800, Ian Lance Taylor wrote: > gcc currently does a relatively crummy job of handling this type of > VLIW architecture. You can describe the dependencies in the > scheduler, but the scheduler won't insert any required nops for you. > The usual approach is walk through the insn chain in the MD reorg pass > and insert nops at that time. For example, look at mips_reorg in > config/mips/mips.c. I've also done it in FINAL_PRESCAN_INSN. It's possible to insert them during sched2; the ia64 port does this. r~
Re: ix86_data_alignment: bad defaults?
> I thought BIGGEST_ALIGNMENT was the largest alignment that the > processor ever requires for any data type. Which is not the > same thing, since this is alignment desired for performance. Since varasm complains when alignment exceeds MAX_OFILE_ALIGNMENT, and MAX_OFILE_ALIGNMENT defaults to BIGGEST_ALIGNMENT, any time we align to something bigger than BIGGEST_ALIGNMENT we need to be careful, then. I like the "min (256, MAX_OFILE_ALIGNMENT)" fix, because that does what we currently do, except when it would complain, then it doesn't. Note that elfos.h defines MAX_OFILE_ALIGNMENT so big that it is effectively unlimited, so no elf target would ever trip over these types of bugs.
Re: ix86_data_alignment: bad defaults?
On Fri, Feb 23, 2007 at 01:42:42PM -0500, DJ Delorie wrote: > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix... So do I. > Note that elfos.h defines MAX_OFILE_ALIGNMENT so big that it is > effectively unlimited, so no elf target would ever trip over these > types of bugs. Yep. r~
GCC 4.3 Stage 1 project survey
I've been trying to keep the GCC_4.3_Release_Planning wiki page up to date, and I'd like to be sure I haven't missed anything going in. I've moved several projects to the Completed section, and if I've done anything in error there, please correct it. So here's a survey of what's left: * AutovectBranchOptimizations The first two subprojects seem to have been checked in, and the other seven haven't. It's hard to tell which of these subprojects are targetted at stage 1 and which at stage 2. * Function Level Control of Optimizations I haven't seen any work on this project on the list. Is it still being worked on? * libgcc-math Seems stalled on RMS, latest message about it here: http://gcc.gnu.org/ml/gcc/2007-01/msg00431.html * PredictiveCommoning I can't tell for sure, as Zdenek commits so many patches ;-) It seems that this one is not merged yet. * PREVNReplacement I spoke to Dan Berlin about this one a few weeks ago and he hadn't finished writing it yet. * Replace_backend_dataflow In progress on dataflow branch. * tuples The initial work seems to have been merged. David Edelsohn asked me to not move this project to completed as apparently there's more work to be done. The projects I think are completed: * TreeRepresentationChanges (2007-02-15) * ipa-branch (2007-01-23) * gcj-eclipse (2007-01-08) * Toplevel libgcc (2007-01-03) * mem-ssa (2006-12-11) * out-of-ssa (2006-12-10) * x86_64/ix86 SSE C99 rounding intrinsics (?) * Record GCC command line switches in object files (2006-12-07) * PREImprovements (2006-10-29/2006-11-14)
Re: GCC 4.3 Stage 1 project survey
On Fri, 23 Feb 2007, Matthew Wilcox wrote: > The projects I think are completed: > > * TreeRepresentationChanges (2007-02-15) Only partly completed. The CALL_EXPR changes have been merged but the TYPE_ARG_TYPES ones haven't yet. (There are many smaller such changes on the LTO branch as well that are small and self-contained enough that they shouldn't need to be merged during Stage 1.) -- Joseph S. Myers [EMAIL PROTECTED]
RE: I need some advice for x86_64-pc-mingw32 va_list calling convention (in i386.c)
See http://msdn2.microsoft.com/en-us/library/ms235286(VS.80).aspx. HTH -- ___ Evandro Menezes AMDAustin, TX > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Kai Tietz > Sent: Friday, February 23, 2007 04:33 > To: gcc > Subject: I need some advice for x86_64-pc-mingw32 va_list > calling convention (in i386.c) > > Hi, > > I am currently on a mingw32 port for x86_64. It is operatable > and I am > allready able to generate the crt-stuff and have some needed > import-libraries. > Executables are linkable and executeable, but wildcard > methods are leading > to wrong execution, as found out. > I detected, that the MS-ABI does not support SSE or MMX > argument passing > (as gcc does for x86_64). Therefore I search some advice about the > enforcement of passing (sse,mmx) registers passing via the standard > integer registers (for MS they are ecx,edx,r9) and via stack. > The current patch for supporting this x86_64-targer I > allready posted to > gcc-patch. > > I would be very pleased, if somebody could give me a hint > about the patch > needed. > > Thank you very much, > i.A. Kai Tietz > > > > >
[Compile Farm] 8 GCC releases with all languages available
Hi, For easy testing I installed 8 GCC releases with all languages including Ada on the Compile Farm machines: * /n/b01/guerby/release/X.Y.Z/bin with X.Y.Z in 3.4.6, 4.0.0-4, 4.1.0-2 has the official GCC X.Y.Z release installed with all languages compiled in, including Ada. If you wish to get an account or know more about the project: http://gcc.gnu.org/wiki/CompileFarm << GCC Compile Farm Project The GCC CompileFarm Project is seeking volunteers to maintain script machinery to help with GCC development on nine bi pentium 3 machines as well as GCC developers that are lacking x86 machine access. How to Get Involved ? If you are a GCC developer and want access to the compileFarm for GCC development and testing, or if you are a free software developer wishing to set up automated testing of a piece of free software with the current GCC development version (preferably with a test suite), please send 1. your ssh public key (HOME/.ssh/authorized_keys format) *in attachment* and not inline in the email and 2. your prefered UNIX login to laurent at guerby dot net. [...] >> Many thanks to the http://jexiste.org/ staff for providing reliable and free hosting to this project. Laurent
Re: ix86_data_alignment: bad defaults?
> > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
>
> So do I.
Ok to apply then? Tested via djgpp cross-compile and cross-host.
* config/i386/i386.c (ix86_data_alignment): Don't specify an
alignment bigger than the object file can handle.
Index: i386.c
===
--- i386.c (revision 122271)
+++ i386.c (working copy)
@@ -15417,7 +15417,7 @@
int
ix86_data_alignment (tree type, int align)
{
- int max_align = optimize_size ? BITS_PER_WORD : 256;
+ int max_align = optimize_size ? BITS_PER_WORD : MIN (256,
MAX_OFILE_ALIGNMENT);
if (AGGREGATE_TYPE_P (type)
&& TYPE_SIZE (type)
Re: ix86_data_alignment: bad defaults?
>
> > > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix...
> >
> > So do I.
>
> Ok to apply then? Tested via djgpp cross-compile and cross-host.
Yes, this is OK. (to be very pedantic, we can assert that
MAX_OFILE_ALIGNMENT>=256 on x86-64 targets, but well). I fully agree with
Richard's interpretation concerning BIGGEST_ALIGNMENT meaning - ie in
special cases for perofrmance it definitly makes sense to use higher
alignments than BIGGEST_ALIGNMENT (such as cache line or page
alignments), BIGGEST_ALIGNMENT is what CPU require and runtime must
provide when asked for.
Honza
>
> * config/i386/i386.c (ix86_data_alignment): Don't specify an
> alignment bigger than the object file can handle.
>
> Index: i386.c
> ===
> --- i386.c(revision 122271)
> +++ i386.c(working copy)
> @@ -15417,7 +15417,7 @@
> int
> ix86_data_alignment (tree type, int align)
> {
> - int max_align = optimize_size ? BITS_PER_WORD : 256;
> + int max_align = optimize_size ? BITS_PER_WORD : MIN (256,
> MAX_OFILE_ALIGNMENT);
>
>if (AGGREGATE_TYPE_P (type)
>&& TYPE_SIZE (type)
Re: ix86_data_alignment: bad defaults?
> > > > > > I like the "min (256, MAX_OFILE_ALIGNMENT)" fix... > > > > > > So do I. > > > > Ok to apply then? Tested via djgpp cross-compile and cross-host. > > Yes, this is OK. (to be very pedantic, we can assert that > MAX_OFILE_ALIGNMENT>=256 on x86-64 targets, but well). I fully agree with > Richard's interpretation concerning BIGGEST_ALIGNMENT meaning - ie in > special cases for perofrmance it definitly makes sense to use higher > alignments than BIGGEST_ALIGNMENT (such as cache line or page > alignments), BIGGEST_ALIGNMENT is what CPU require and runtime must > provide when asked for. One extra bit - we do use alignments of base > 32 bytes for code alignment. What would be the behaviour on targets with MAX_OFILE_ALIGNMENT set to 16 bytes? I.e. if we end up with gas producing many nops that would then on random basis end up 16 or 32 byte aligned, it might be good idea to forcingly reduce alignments to base 16 on those targets. Honza
Re: ix86_data_alignment: bad defaults?
On Feb 23, 2007, at 1:46 PM, Jan Hubicka wrote: One extra bit - we do use alignments of base > 32 bytes for code alignment. What would be the behaviour on targets with MAX_OFILE_ALIGNMENT set to 16 bytes? min (MAX_OFILE_ALIGNMENT, 32) of course. I.e. if we end up with gas producing many nops that would then on random basis end up 16 or 32 byte aligned, it might be good idea to forcingly reduce alignments to base 16 on those targets. Agreed. The assembler should produce a hard error if one asks it for an alignment that can't be satisfied.
gcc-4.3-20070223 is now available
Snapshot gcc-4.3-20070223 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20070223/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 122274 You'll find: gcc-4.3-20070223.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20070223.tar.bz2 C front end and core compiler gcc-ada-4.3-20070223.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20070223.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20070223.tar.bz2 C++ front end and runtime gcc-java-4.3-20070223.tar.bz2 Java front end and runtime gcc-objc-4.3-20070223.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20070223.tar.bz2The GCC testsuite Diffs from 4.3-20070216 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: ix86_data_alignment: bad defaults?
> The assembler should produce a hard error if one asks it for an > alignment that can't be satisfied. The djgpp assembler quietly ignores such requests (not intentional); the object file just stops at 2**4. I only noticed the bug because gcc itself complains, and with -Werror (as djgpp and binutils use), the build just fails.
Re: ix86_data_alignment: bad defaults?
> Yes, this is OK. Thanks, applied. > (to be very pedantic, we can assert that MAX_OFILE_ALIGNMENT>=256 on > x86-64 targets, but well). My head hurts at the thought of x86_64-aout. > I fully agree with Richard's interpretation concerning > BIGGEST_ALIGNMENT meaning - ie in special cases for perofrmance it > definitly makes sense to use higher alignments than > BIGGEST_ALIGNMENT (such as cache line or page alignments), > BIGGEST_ALIGNMENT is what CPU require and runtime must provide when > asked for. Something like this, then? Index: tm.texi === --- tm.texi (revision 122271) +++ tm.texi (working copy) @@ -1068,7 +1068,9 @@ Alignment required for a function entry @end defmac @defmac BIGGEST_ALIGNMENT -Biggest alignment that any data type can require on this machine, in bits. +Biggest alignment that any data type can require on this machine, in +bits. Note that this is not the biggest alignment that is supported, +just the biggest alignment that, when violated, may cause a fault. @end defmac @defmac MINIMUM_ATOMIC_ALIGNMENT
Auto Vectorizing help needed
I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit additions, subtractions, multiplications & shift operations simultaneously. I would like to use the Auto-Vectorizing capability to generate these instructions. Is there an existing backend that I could look at for something similar? Any help will be greatly appreciated. SD
Re: ix86_data_alignment: bad defaults?
On Fri, Feb 23, 2007 at 06:19:28PM -0500, DJ Delorie wrote: > Something like this, then? Sure. r~
Re: Auto Vectorizing help needed
On Fri, Feb 23, 2007 at 04:13:39PM -0800, sdutta wrote: > I am targeting GCC 4.1.1 to a custom RISC processor; which has some vector > instructions (32 bit vectors). It can perform two 16 bit/ or four 8 bit > additions, subtractions, multiplications & shift operations simultaneously. > > I would like to use the Auto-Vectorizing capability to generate these > instructions. Is there an existing backend that I could look at for > something similar? Any help will be greatly appreciated. The cleanest example may be located in gcc/config/ia64/vect.md. r~
Re: Comparison of Itanium gcc 4.1 and 4.2 on Spec2000
On Fri, Feb 23, 2007 at 11:09:29AM -0500, Vladimir N. Makarov wrote: > Yes, that is the current state of 4.1 and 4.2 branches (as of > yesterday). I don't think we will see a change with the reverted > alaising patches for itanium because conservative aliasing most probably > will be compensated by itanium hardware (itanium speculation insn > support was added for 4.2). Perhaps I'm missing something obvious, but often conservative aliasing results in reading lots of extra data from memory. How can speculation compensate for that? It seems that the best you can do is reduce the penalty, if you can do something in parallel with the extra I/O.
Re: Fold and integer types with sub-ranges
> That said, this whole thing is a can of worms. Suppose the compiler wants to > calculate t+1. Of course you do something like this: > > int_const_binop (PLUS_EXPR, t, build_int_cst (TREE_TYPE (t), 1), 0); > > But if 1 is not in the type of t, you just created an invalid value! Yes, but why not do all arithmetic in the base type, just like Ada itself does? Then you use 1 in that base type. > Personally I think the right thing to do is to eliminate these types > altogether somewhere early on, replacing them with their base types > (which don't have funky ranges), inserting appropriate ASSERT_EXPRs > instead. Probably types like t should never be seen outside the Ada > f-e at all. Not clear. There is the debug issue plus VRP can use the range information for some things (we have to be very precise as to what). If we keep the model of doing all arithmetic in the base type, there should be no problem.
Re: Comparison of Itanium gcc 4.1 and 4.2 on Spec2000
Joe Buck wrote: Perhaps I'm missing something obvious, but often conservative aliasing results in reading lots of extra data from memory. How can speculation compensate for that? It seems that the best you can do is reduce the penalty, if you can do something in parallel with the extra I/O. You can speculate that a memory location is not changed, and if it is then and only then do you get the extra load?
Re: ix86_data_alignment: bad defaults?
> > Something like this, then? > > Sure. Committed, then.
Re: ix86_data_alignment: bad defaults?
> I thought BIGGEST_ALIGNMENT was the largest alignment that the > processor ever requires for any data type. That's my understanding of what it was originally *supposed* to be, though it wouldn't surprise me all that much if it were used in subtly different ways in some places.
Re: Comparison of Itanium gcc 4.1 and 4.2 on Spec2000
Joe Buck <[EMAIL PROTECTED]> writes: > On Fri, Feb 23, 2007 at 11:09:29AM -0500, Vladimir N. Makarov wrote: > > Yes, that is the current state of 4.1 and 4.2 branches (as of > > yesterday). I don't think we will see a change with the reverted > > alaising patches for itanium because conservative aliasing most probably > > will be compensated by itanium hardware (itanium speculation insn > > support was added for 4.2). > > Perhaps I'm missing something obvious, but often conservative aliasing > results in reading lots of extra data from memory. How can speculation > compensate for that? It seems that the best you can do is reduce the > penalty, if you can do something in parallel with the extra I/O. On an in-order processor, the biggest effect of conservative aliasing is not so much extra memory reads as it is poor scheduling of existing memory reads. And better speculation can improve scheduling in general. Ian
