Re: (define_mode_const), a proposal
Uros Bizjak schrieb:
> Hello!
>
> During the macroization of x86 RTX patterns, it became clear that
> certain patterns can't be macroized due to mode-dependant (const_int
> N) RTXes, where the value of X depends on current mode. As an example,
> here are two insn patterns from i386/i386.md:
>
> (define_insn "x86_64_shld"
> [(set (match_operand:DI 0 "nonimmediate_operand" "+r*m")
> (ior:DI (ashift:DI (match_dup 0)
> (match_operand:QI 2 "nonmemory_operand" "Jc"))
> (lshiftrt:DI (match_operand:DI 1 "register_operand" "r")
> (minus:QI (const_int 64) (match_dup 2)
>(clobber (reg:CC FLAGS_REG))]
> ...
>
> and
>
> (define_insn "x86_shld"
> [(set (match_operand:SI 0 "nonimmediate_operand" "+r*m")
> (ior:SI (ashift:SI (match_dup 0)
> (match_operand:QI 2 "nonmemory_operand" "Ic"))
> (lshiftrt:SI (match_operand:SI 1 "register_operand" "r")
> (minus:QI (const_int 32) (match_dup 2)
>(clobber (reg:CC FLAGS_REG))]
> ""
> ...
>
> These two patterns could easily be macroized, however - there is no
> way to express (const_int N) mode dependency*.
>
> If we have had a define_mode_constant expression, similar to
> define_mode_attr, where:
>
> (define_mode_const WSZ [(SI "32") (DI "64")])
>
> we could macroize the pattern to:
>
> (define_insn "shld_"
> [(set (match_operand:SWI48 0 "nonimmediate_operand" "+r*m")
> (ior:SWI48 (ashift:SWI48 (match_dup 0)
> (match_operand:QI 2 "nonmemory_operand" "c"))
> (lshiftrt:SWI48 (match_operand:SWI48 1 "register_operand" "r")
> (minus:QI (const_int {WSZ}) (match_dup 2)
>(clobber (reg:CC FLAGS_REG))]
> ""
> ...
>
> where {WSZ} would get expanded to correct number through WSZ
> define_mode_const.
>
> This would help to macroize various push instructions throughout
> i386.md and (more important) numerous string instructions, in addition
> to the patterns, similar to the example above.
What about this?
(define_insn "shld_"
[(set (match_operand:SWI48 0 "nonimmediate_operand" "+r*m")
(ior:SWI48 (ashift:SWI48 (match_dup 0)
(match_operand:QI 2 "nonmemory_operand"
"c"))
(lshiftrt:SWI48 (match_operand:SWI48 1 "register_operand"
"r")
(minus:QI (match_operand:SWI48 3
"const_int_operand" "n")
(match_dup 2)
(clobber (reg:CC FLAGS_REG))]
"GET_MODE_BITSIZE (mode) == INTVAL (operands[3])"
Georg
Re: Attributes
Sean Hunt writes: > On 07/10/2010 03:56 PM, Ian Lance Taylor wrote: >> Sean Hunt writes: >> >>> void foo () __attribute__((noreturn)); // right per spec >>> void foo __attribute__((noreturn)) (); // works >>> __attribute__((noreturn)) void foo (); // works >>> >>> It's obvious that the first example of each kind (noreturn appearing >>> after the function declarator) must be accepted if it's a GCC >>> attribute and not if it's a C++0x attributes. The later two (noreturn >>> appearing before the declaration or after the identifier) must be >>> accepted for C++0x attributes, but it's not clear if the GCC syntax >>> being accepted is an accident or by design. >> >> As far as I can see they are both documenated as working at >> http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/Attribute-Syntax.html , so I >> think it is by design. > > The problem is that it is not clear if that is intended, or merely an > accident. The spec is rather unclear about a number of things. I'm not sure what sort of answer you are looking for. Attributes were implemented in gcc without any sort of design or spec. They were and are used in many programs. We don't want to break those programs. The current documentation describes how attributes work, and is intended to be a guide both for gcc maintainers and for gcc users. The documentation describes for users how attributes may be used, and describes for maintainers what is supposed to work. So when you ask whether the syntax is intended or is an accident, the answer is more or less that both are the case. It's not an either/or situation. >>> Is anyone currently working on C++0x attributes in GCC and, if not, is >>> there anyone who can help me through what we should and shouldn't >>> accept in clang? >> >> I don't know the answer to this. It's clear that C++0x attributes are >> not the same as GNU attributes. > > Yes. I'm trying to determine which parts of GCC attributes are merely > accidents and don't really need implementation, as there are a lot of > situations where GCC attributes (as implemented) are significantly > more liberal than C++0x attributes are. This will be an issue that GCC > developers will encounter when an effort is made to implement > attributes; I would like to see what discussion can be had before I go > ahead and reimplement the attribute codepaths within clang. I'm not working on implementing C++0x attributes in GCC. However, my answer would be that you should implement gcc attributes according to the gcc docs and implement C++0x attributes according to the C++0x final committee draft. They are obviously related, but they are not the same thing. It would be a mistake to implement them both in the same way, at least when it comes to syntax. Ian
GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
Is there a document or standard (or group of standards) that define the collective ABIs of GNU/Linux systems using ELF binary formats of various CPU architectures, including at least: IA32 (i386/i686/AMD64/EMT64/etc...) ARM (v5, v5t, v7, etc...) What is the policy of the GNU toolchain, does it attempt to support a super-set of features where code was contributed but not directly set/enforce policy itself. This being a matter for a distribution creator to establish. My concern comes from what looks to be non-backwards compatible changes being made by the MeeGo distribution of Linux. Specifically the enablement of SSSE3 IA32 instructions for "general purpose code generation", one possible motive for this is that a particular hardware vendor can claim in marketing the platform is optimized for XYZ technology/product, the thing they are actively trying to sell of the day. This doesn't necessarily make for a good engineering choice. While I accept that any distribution can do what they want, given the choice and resources I might wish to rebuild the entire open source project based around a better set of rules over this matter, since I have an interest in using the software but being a developer want the least amount of headaches looking into the future. I also wish to achieve the goals to be able to provide a fully native SSSE3 optimized complete system but want other systems to behave in a repeatable and consistent way when binaries ultimately end up shared across them (desktop Linux). Does GCC support use of newer CPU instructions for "general purpose code generation" ? If so what kind of situations might they get selected for use ? It is possible the situation is being misinterpreted by me, if GCC can not actually schedule newer instructions in code generation. So my next question is what support is there in the various formats, technologies and runtime libraries to provide a backwards compatible solution, such that a binary from one system when put on another can have any hardware incompatibilities detected at the soonest opportunity, for example upon execution, soon after execution, during DSO loading: 1) ELF magic or hwcap (this would allow the kernel to error during the exec() system call, knowing that the format is not supported by the system). DSOs loaded would also error with the same checking. Ideally a hwcap system ideally doesn't want to be a rigid bitmask but some kind of extensible ASN.1 system where anyone can register for their own hierarchical domain and assign whatever they want from within it. 2) Use of a bespoke/custom Dynamic Linker path, I would guess any system doing this would be free to implement an alternative ABI. Mixing binaries between systems would result in them not working due to lack of Dynamic Linker at that path. 3) Do the ABIs directly discuss of explain how such matters should be addressed, i.e. by guarding the execution of new CPU instructions by runtime checking. This might mean whole optimized DSOs are loaded instead, or it might mean bunch of symbols would be redirected to optimized code within the same DSO, or it might mean an inline change of the flow of execution. While I understand ABIs maybe open/loose/ambigious to allow new technologies and ideas to exist when known interoperability problems appear then guidelines should exist that provide technical answers to guide implementers so that good citizenship may follow. 4) Use of some ELF section to describe additional runtime checking rules. The problem stems from hit and miss users getting SIGILL due to use of unguarded IA32 instructions being executed on non compatible (older) CPUs. The kernel doesn't provide any trap and emulation, so the general purpose applications abort resulting is possible data loss. Do guidelines exist within the GNU/Linux ABI on how to be a "good citizen" and help systems differentiate incompatible binaries so they simply don't run instead of causing a SIGILL potentially some months after execution started, because over the entire executable only a tiny handful of these instructions got selected by the compiler for use and that code didn't get run for a long time after the executable started. The next matter is has anyone done any studies on the performance difference when enablement of newer instructions is possible for "general purpose code generation". I'm not so interested in specialized use cases such as codecs, compression, encryption, graphics, etc... I consider these specialized use cases for which many applications and libraries already have a workable solution by "guarding" the execution of instructions that optimize such algorithms by checking the CPU runtime support. I'm interested in the facts on how much benefit regular code gets from this choice. Thanks, Darryl
Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
> > Is there a document or standard (or group of standards) that define the > collective ABIs of GNU/Linux systems using ELF binary formats of various > CPU architectures, including at least: > IA32 (i386/i686/AMD64/EMT64/etc...) > ARM (v5, v5t, v7, etc...) x86_64 ABI is at www.x86-64.org/documentation/abi.pdf You can find similar processor supplements for other architectures. > My concern comes from what looks to be non-backwards compatible changes > being made by the MeeGo distribution of Linux. Specifically the > enablement of SSSE3 IA32 instructions for "general purpose code > generation", one possible motive for this is that a particular hardware GCC has -march switch specifying what ISA you want to generate for. By default, GCC won't use SSSE3 or other extensions on i386 nor x86_64 target, but distribution, at its own choice, might change the default. When configured to use extended ISA, GCC is trying to autogenerate new instructions in generic code. It naturally depends on type of instructions: many of new SSE instructions are very exotic and not fitting generic codegen and are available only via special builtins. Honza
Triplet for ARM Linux HardFP ABI
Hi All, Both Linaro and Debian are considering supporting the ARM hard-float variant of the EABI, at least as an unofficial port. This ABI is not compatible with the gnueabi currently in use for most ARM Linux distros, but has a number of performance advantages. This means that we need to choose a name for it. Obviously, it's better if it's an "official" name, so I want to discuss it here. I'm aware that there is some bikeshedding to do here, but it's better it gets done before anybody gets stuck with something else. There are, of course, some real practical reasons why one name might be better than another. So here are my suggestions: arm-linux-gnueabihf or maybe arm-linux-gnueabi-hf These will match any package that uses arm*-*-linux-gnueabi*. Choosing which variant is mainly a matter of taste. arm-linux-gnuhfeabi These will match any package that uses arm*-*-linux-*eabi (as I see gcc itself does). I'm not sure which is better. I suspect that, either way, a lot of things will need to be fixed up. An alternative would be to use the vendor field. That would be less difficult, but it feels like something of a hack to me. FAOD, the new triplet would only set the default ABI variant. This can already be achieved via configure options, so this adds no real new functionality. This is just about agreeing how to label it. Andrew Stubbs CodeSourcery (currently working with Linaro)
Re: Triplet for ARM Linux HardFP ABI
Quoting Andrew Stubbs : Hi All, Hi, long time no see... So here are my suggestions: arm-linux-gnueabihf or maybe arm-linux-gnueabi-hf I don't like the inflation of dashes - it breaks scripts that want to parse the host triplet / quadruplet (IMO having a quadruplets was already a step in the wrong direction) how about using an underscore instead to distinguish separate pieces of the OS/ABI: arm-linux-gnueabi_hf arm-linux-gnuhfeabi or arm-linux-gnu_hf_eabi if we could turn back the clock, I'd even prefer arm-linux_gnu_hf_eabi to get back to a single '-'-parsed OS string, but the linux-gnu stuff is now entrenched, so trying to change back would only cause more disruption.
Re: GNU/Linux ABI documentation ? GCC supports SSSE3 in general purpose code generation ?
> So my next question is what support is there in the various formats, > technologies and runtime libraries to provide a backwards compatible > solution, such that a binary from one system when put on another can > have any hardware incompatibilities detected at the soonest opportunity, > for example upon execution, soon after execution, during DSO loading: You can configure GCC to default to whatever ISA you like. Unless you (the person building GCC) specified otherwise, it will usually choose something fairly conservative. If you have been given a toolchain or binaries that is not suitable for you system, then that is something you should probably take up with whoever supplied them. My understanding is that glibc has limited facilites for picking different set of libraries at runtime, but will not disgnose mismatches in a graceful fasion. Either way this is probably an assembler/linker problem rather than a compiler problem. GNU as/ld do support thin kind of object file annotation, though the level of support varies between targets. Paul
Re: Triplet for ARM Linux HardFP ABI
On Mon, 2010-07-12 at 10:23 -0400, Joern Rennecke wrote: > Quoting Andrew Stubbs : > > > Hi All, > > Hi, long time no see... > > > So here are my suggestions: > > > > arm-linux-gnueabihf > >or maybe > > arm-linux-gnueabi-hf > > I don't like the inflation of dashes - it breaks scripts that want to > parse the host triplet / quadruplet (IMO having a quadruplets was already > a step in the wrong direction) > > how about using an underscore instead to distinguish separate pieces of > the OS/ABI: > arm-linux-gnueabi_hf > > > arm-linux-gnuhfeabi > > or arm-linux-gnu_hf_eabi > > if we could turn back the clock, I'd even prefer > > arm-linux_gnu_hf_eabi to get back to a single '-'-parsed OS string, but > the linux-gnu stuff is now entrenched, so trying to change back would only > cause more disruption. quadruplets, quintuplets and even sextuplets wouldn't be a problem if all the preceding parts were compulsory. The problem is that the vendor field is optional, so now arm-linux-gnueabi is ambiguous. Is that a quadruplet that's missed out the vendor part, or a triplet? R.
Re: Triplet for ARM Linux HardFP ABI
> Both Linaro and Debian are considering supporting the ARM hard-float > variant of the EABI, at least as an unofficial port. This ABI is not > compatible with the gnueabi currently in use for most ARM Linux distros, > but has a number of performance advantages. > > This means that we need to choose a name for it. I don't think we do. IMO there's no reason (other than dpkg lameness) why soft-float and hard-float toolchains should have a different target triplet. You can (and people do) already build a hard-float toolchain by specifying --with-float=hard. Anything that rely on the that relies on the target triplet to determine hard v.s. soft-float ABI is fundamentally broken. In a restricted environment (e.g. Debian package builds) you may have a fixed mapping, and even that's liable to fall apart in a multiarch environment. Given you're already making vendor specific assumptions, it seems reasomablt to determing the ABI by vendor-specific means. Of course the real solution if to make the check independent of the triplet. GCC doesn't currently define a preprocessor symbol for the ABI, but that's a separate bug. > Obviously, it's better > if it's an "official" name, so I want to discuss it here. I'm aware that > there is some bikeshedding to do here, but it's better it gets done > before anybody gets stuck with something else. There are, of course, > some real practical reasons why one name might be better than another. > So here are my suggestions: > >arm-linux-gnueabihf > or maybe >arm-linux-gnueabi-hf > > These will match any package that uses arm*-*-linux-gnueabi*. > Choosing which variant is mainly a matter of taste. > >arm-linux-gnuhfeabi > > These will match any package that uses arm*-*-linux-*eabi (as I > see gcc itself does). > > I'm not sure which is better. I suspect that, either way, a lot of > things will need to be fixed up. I think "hf" is wrong. This is specifically the vfp EABI supplement. In principle we should allow for other ABI variants (e.g. FPA, Maverick). > An alternative would be to use the vendor field. That would be less > difficult, but it feels like something of a hack to me. This would be my preferred solution. When all said an done this *is* a hack round a deficiency in your build system. I'm reluctant to propagate that into gcc. It's worth noting that a while ago we made the deliberate decision to start ignoring the cpu field. Previously configuring for xscale-elf would do magical things. Also notice that blindly configuring for armeb-linux-eabi still gives you a little-endian toolchain. Paul
Re: Triplet for ARM Linux HardFP ABI
On Mon, 2010-07-12 at 16:03 +0100, Paul Brook wrote: > > Both Linaro and Debian are considering supporting the ARM hard-float > > variant of the EABI, at least as an unofficial port. This ABI is not > > compatible with the gnueabi currently in use for most ARM Linux distros, > > but has a number of performance advantages. > > > > This means that we need to choose a name for it. > > I don't think we do. IMO there's no reason (other than dpkg lameness) why > soft-float and hard-float toolchains should have a different target triplet. > > You can (and people do) already build a hard-float toolchain by specifying > --with-float=hard. > The reason why a new triplet is required is that config.guess needs to generate it when running native. Config.guess is the only way to communicate the information needed for a native compiler when no other information is communicated on the command line, and it only reports a triplet. Yet it's essential that the right ABI gets selected in this case, or you'll have a non-functional toolchain. That is, on a native machine .../configure --prefix=... must build a native compiler that conforms to the native ABI of the machine. > Anything that rely on the that relies on the target triplet to determine hard > v.s. soft-float ABI is fundamentally broken. In a restricted environment > (e.g. Debian package builds) you may have a fixed mapping, and even that's > liable to fall apart in a multiarch environment. Given you're already making > vendor specific assumptions, it seems reasomablt to determing the ABI by > vendor-specific means. > > Of course the real solution if to make the check independent of the triplet. > GCC doesn't currently define a preprocessor symbol for the ABI, but that's a > separate bug. > Indeed. The draft ACLE specification has one __ARM_PCS_VFP, but that document hasn't been published yet. > > Obviously, it's better > > if it's an "official" name, so I want to discuss it here. I'm aware that > > there is some bikeshedding to do here, but it's better it gets done > > before anybody gets stuck with something else. There are, of course, > > some real practical reasons why one name might be better than another. > > > So here are my suggestions: > > > >arm-linux-gnueabihf > > or maybe > >arm-linux-gnueabi-hf > > > > These will match any package that uses arm*-*-linux-gnueabi*. > > Choosing which variant is mainly a matter of taste. > > > >arm-linux-gnuhfeabi > > > > These will match any package that uses arm*-*-linux-*eabi (as I > > see gcc itself does). > > > > I'm not sure which is better. I suspect that, either way, a lot of > > things will need to be fixed up. > > I think "hf" is wrong. This is specifically the vfp EABI supplement. In > principle we should allow for other ABI variants (e.g. FPA, Maverick). FPA isn't legal in the EABI. Maverick is incompatible with the Hard-float variant. I accept your point, however, that maybe this should be conveyed more clearly in the name, but in reality, VFP is now *the* way to do hardware floating point on ARM. > > > An alternative would be to use the vendor field. That would be less > > difficult, but it feels like something of a hack to me. > > This would be my preferred solution. When all said an done this *is* a hack > round a deficiency in your build system. I'm reluctant to propagate that into > gcc. FWIW, I can't say I like the idea of using the vendor field for this, but I don't have a particularly strong opinion on that matter. It is true that the vendor field in the triplet is essentially useless today for Linux; but I'm not (yet) convinced that (ab)using it for ABI variant information is the right way to go. > > It's worth noting that a while ago we made the deliberate decision to start > ignoring the cpu field. Previously configuring for xscale-elf would do > magical > things. Also notice that blindly configuring for armeb-linux-eabi still > gives > you a little-endian toolchain. > The change, I think, was to stop magically changing the ABI rules based on the CPU name, not to ignore it completely: I'd expect xscale to cause v5 code to be generated (unless specifically overridden with --with-cpu). R.
Re: Triplet for ARM Linux HardFP ABI
On 12/07/10 15:51, Richard Earnshaw wrote: if we could turn back the clock, I'd even prefer arm-linux_gnu_hf_eabi to get back to a single '-'-parsed OS string, but the linux-gnu stuff is now entrenched, so trying to change back would only cause more disruption. quadruplets, quintuplets and even sextuplets wouldn't be a problem if all the preceding parts were compulsory. The problem is that the vendor field is optional, so now arm-linux-gnueabi is ambiguous. Is that a quadruplet that's missed out the vendor part, or a triplet? Right, hence arm-none-linux-gnueabi. I forgot about that, but I'm only really talking about the OS part here anyway. Andrew
Re: Triplet for ARM Linux HardFP ABI
> .../configure --prefix=... > > must build a native compiler that conforms to the native ABI of the > machine. By my reading at least ppc, mips and sparc allow the default ABI to be changed via --with-float, but none of them have a separate target triplet for this purpose. > > It's worth noting that a while ago we made the deliberate decision to > > start ignoring the cpu field. Previously configuring for xscale-elf > > would do magical things. Also notice that blindly configuring for > > armeb-linux-eabi still gives you a little-endian toolchain. > > The change, I think, was to stop magically changing the ABI rules based > on the CPU name, not to ignore it completely: I'd expect xscale to > cause v5 code to be generated (unless specifically overridden with > --with-cpu). It does not. Part of the problem here is whether you want to default to the system you're running on, or the hardware you're running on. Unfortunately config.guess returns the latter, so obeying the cpu name effectively makes us default to --with-arch=native. Paul
Re: Triplet for ARM Linux HardFP ABI
Richard Earnshaw wrote: > The reason why a new triplet is required is that config.guess needs to > generate it when running native. Config.guess is the only way to > communicate the information needed for a native compiler when no other > information is communicated on the command line, and it only reports a > triplet. Why not fix this? For example, it could also give back configure options (--with-float=hard) that should be implicitly assumed to have been provided. It really does seem like a hack to use triplets in this way; I think Paul's point that anything that depends on the toolchain triplet to determine ABI is inherently busted is pretty persuasive. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
Re: Triplet for ARM Linux HardFP ABI
On Mon, 2010-07-12 at 09:19 -0700, Mark Mitchell wrote: > Richard Earnshaw wrote: > > > The reason why a new triplet is required is that config.guess needs to > > generate it when running native. Config.guess is the only way to > > communicate the information needed for a native compiler when no other > > information is communicated on the command line, and it only reports a > > triplet. > > Why not fix this? For example, it could also give back configure > options (--with-float=hard) that should be implicitly assumed to have > been provided. That would be useful for GCC perhaps, but not for other projects that use config.guess (which is part of the generic GNU infrastructure). If those extra args could be made invisible to other users; then that might be a way forward. > > It really does seem like a hack to use triplets in this way; I think > Paul's point that anything that depends on the toolchain triplet to > determine ABI is inherently busted is pretty persuasive. > Which means the whole GNU way of doing this has always been busted, since that's essentially how the world has always worked... :-) R.
Re: Triplet for ARM Linux HardFP ABI
> > It really does seem like a hack to use triplets in this way; I think > > Paul's point that anything that depends on the toolchain triplet to > > determine ABI is inherently busted is pretty persuasive. > > Which means the whole GNU way of doing this has always been busted, > since that's essentially how the world has always worked... :-) Um, I though that GNU (autoconf) way of doing things was to test for features, rather than relying on hardcoded per-system mappings. Paul
Re: Triplet for ARM Linux HardFP ABI
Richard Earnshaw wrote: >> Why not fix this? For example, it could also give back configure >> options (--with-float=hard) that should be implicitly assumed to have >> been provided. > > That would be useful for GCC perhaps, but not for other projects that > use config.guess (which is part of the generic GNU infrastructure). If > those extra args could be made invisible to other users; then that might > be a way forward. Presumably config.guess would be passed a new argument that causes it to produce this extra output. >> It really does seem like a hack to use triplets in this way; I think >> Paul's point that anything that depends on the toolchain triplet to >> determine ABI is inherently busted is pretty persuasive. > > Which means the whole GNU way of doing this has always been busted, > since that's essentially how the world has always worked... :-) Well, indeed. There's always the question of when one ought to go clean up the mess and when one ought to just go with the flow. We've seen these kinds of problems on every embedded architecture; MIPS, for example, has suffered rather badly from this problem. Deriving ABI behavior from triplets is a problem that's caused brokenness for multilib'd toolchains in various packages. -- Mark Mitchell CodeSourcery m...@codesourcery.com (650) 331-3385 x713
PR middle-end/44878 & REFERENCE variable mode & IA64 32 bit mode
I am looking at PR 44787 where IA64 HP-UX (in 32 bit mode) is failing to
compile this test case:
class e {
public:
e(void* __e);
e(const e&);
};
void * v() { }
e foo() { return e(v()); }
This test dies trying to copy an SImode register to a DImode register
and emit_move_insn complains because the modes don't match. Tracking
this back showed me that the failure starts with r161898 (partial inlining)
where needs_to_live_in_memory was changed so that it no longer returns
true for reference arguments. Undoing that change results in a good compiler
but I think the code (as it is) should be OK, we can just pass the
reference as a pointer which I think is what the compiler is trying to do,
it is just confused about whether to pass it in SImode (ptr_mode) or
DImode (Pmode) on IA64 in 32 bit mode.
I am looking for advice on where and how to fix it (should I pass reference
arguments in SImode or DImode). I think they should be passed like pointers
in SImode (since pointers are SImode
I had good luck modifying assign_parms with this patch:
Index: function.c
===
--- function.c (revision 161898)
+++ function.c (working copy)
@@ -3317,7 +3317,7 @@ assign_parms (tree fndecl)
rtx x;
if (DECL_BY_REFERENCE (result))
- x = addr;
+ x = convert_memory_address (ptr_mode, addr);
else
{
addr = convert_memory_address (Pmode, addr);
But I am not sure if this is the right fix either. I looked into
why addr was in Pmode (instead of ptr_mode) to begin with and it
seems to come from promote_mode. assign_parm_setup_reg is calling
promote_function_mode (with a reference), that calls promote_mode,
and for a reference promote_mode calls targetm.addr_space.address_mode
which returns Pmode. So that is how I get Pmode to start with.
I modified the IA64 specific promote_function_mode to return ptr_mode
for reference types:
#ifdef POINTERS_EXTEND_UNSIGNED
if (TREE_CODE (type) == REFERENCE_TYPE)
return ptr_mode;
#endif
but that resulted in a ICE in expand_expr_real_1. Any attempts to
change this function (or the address_mode function) seem to affect
other areas of the compilation and result in various ICE failures.
Any comments on the working patch or on where this change should
be made?
Steve Ellcey
s...@cup.hp.com
struct tree_type
Hello, I did a quick search on "gcc internal" document and cannot find any explanation about the field meaning of struct tree_type. I am trying to use typedef to introduce some new aggregrate types that my gcc can handle. And I want to mark these types so that I can handle these types specifically. I might have to differenciate my own types into several categories, therefore I need several marking bits. My application will be in C/C++. Is there any fields that I can recycle? Or it is better to introduce some new fields. Can somebody quickly explain what the bit fields are for? thanks unsigned int precision : 10; unsigned no_force_blk_flag : 1; unsigned needs_constructing_flag : 1; unsigned transparent_aggr_flag : 1; unsigned restrict_flag : 1; unsigned contains_placeholder_bits : 2; ENUM_BITFIELD(machine_mode) mode : 8; unsigned string_flag : 1; unsigned lang_flag_0 : 1; unsigned lang_flag_1 : 1; unsigned lang_flag_2 : 1; unsigned lang_flag_3 : 1; unsigned lang_flag_4 : 1; unsigned lang_flag_5 : 1; unsigned lang_flag_6 : 1; _ Game on: Challenge friends to great games on Messenger http://go.microsoft.com/?linkid=9734387
RE: Compilation time in gcc-4.4.0
33 minutes to 39 second? that sounds a drastic improvement. The performance improvement is also amazing. You can try to divide your program into subphases and measure the biggest change in time and then focus on parts that contribute to the most improvement. Sometimes it is can be done quickly through comparing the optimization log/IR dumpings/assembly. if everything is right, your paper probably is a good story to tell. But before that, I guess the compiler is quite noisey. :) > From: i...@google.com > To: maxiw...@gmail.com > CC: gcc@gcc.gnu.org > Subject: Re: Compilation time in gcc-4.4.0 > Date: Sat, 10 Jul 2010 15:04:02 -0700 > > Maxiwell Garcia writes: > >> I am writing a paper about instruction-set architecture simulators. In >> first time, I used gcc-4.4.0 and the compilation time reached 33 >> minutes (with -O3) for my simulator and the performance reached 270 >> MIPS (Million instruction per second). When I used the gcc-4.4.4, in >> the same code, the compilation time reached 39 seconds and the >> performance reached 600 MIPS. My code have many "switchs" with 512 >> "cases" and the library is in use. >> How to explain this behavior in the compilation and performance in my paper? > > If I'm reading this correctly, it sounds like a useful optimization fix > in gcc 4.4.4. The compiler runs faster and generates better code. > > So I'm not sure what your question is. Are you asking us why gcc has > gotten better? > > Ian _ Learn more ways to connect with your buddies now http://go.microsoft.com/?linkid=9734388
GCC Bugzilla is broken now
I got this when trying to access http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44921 Software error: Can't rename data/versioncache.Xg5KN to versioncache at globals.pl line 306. For help, please send mail to the webmaster (sourcemas...@sourceware.org), giving this error message and the time and date of the error. It was OK just two or three hours ago. -- Jie Zhang CodeSourcery
A question about patch submission
Hi, I want to submit a patch about loongson 3A, a new architecture different from loongson 2E & 2F. My patch is based on Gcc4.4.0. If I want to submit my patch, which branch shoud I submit to, gcc4.4.0 branch or I should change the patch to suite with the main branch. Thanks, Mingming Sun
Re: A question about patch submission
On 07/13/2010 11:56 AM, Mingming Sun wrote: Hi, I want to submit a patch about loongson 3A, a new architecture different from loongson 2E& 2F. My patch is based on Gcc4.4.0. If I want to submit my patch, which branch shoud I submit to, gcc4.4.0 branch or I should change the patch to suite with the main branch. Yes. You need port your patch to SVN trunk before submit it. -- Jie Zhang CodeSourcery
Re: A question about patch submission
Do you mean I must submit it to the main brach? On Tue, Jul 13, 2010 at 12:17 PM, Jie Zhang wrote: > On 07/13/2010 11:56 AM, Mingming Sun wrote: >> >> Hi, >> >> I want to submit a patch about loongson 3A, a new architecture >> different from loongson 2E& 2F. >> My patch is based on Gcc4.4.0. >> If I want to submit my patch, which branch shoud I submit to, gcc4.4.0 >> branch or I should change the patch to >> suite with the main branch. >> > Yes. You need port your patch to SVN trunk before submit it. > > > -- > Jie Zhang > CodeSourcery >
Re: A question about patch submission
On 07/13/2010 12:20 PM, Mingming Sun wrote: On Tue, Jul 13, 2010 at 12:17 PM, Jie Zhang wrote: On 07/13/2010 11:56 AM, Mingming Sun wrote: I want to submit a patch about loongson 3A, a new architecture different from loongson 2E&2F. My patch is based on Gcc4.4.0. If I want to submit my patch, which branch shoud I submit to, gcc4.4.0 branch or I should change the patch to suite with the main branch. Yes. You need port your patch to SVN trunk before submit it. > Do you mean I must submit it to the main brach? Please don't top reply. (I have moved your reply down.) I'm not sure if I understand you. GCC source code is maintained in SVN repository, which has a trunk and many branches. The trunk is where the main development is going on. gcc4.4.0 is not a branch. It is a release, which is created from branch gcc-4_4-branch. When you submit a patch like this, you need to create your patch against SVN trunk instead of any branch or tag or release tarball. -- Jie Zhang CodeSourcery
