Re: ARM EABI ZCX Ada (4.6.1) almost working
> On further thinking about this, I have a feeling this may have something > to do with the Private1 field of the unwind_exception, but I'm not too > sure how yet. For sure, adding a couple of fields on the Ada side that don't exist on the C side is highly suspicious. Better get rid of them in any case I'd think. -- Eric Botcazou
Re: ARM EABI ZCX Ada (4.6.1) almost working
> On further thinking about this, I have a feeling this may have something > to do with the Private1 field of the unwind_exception, but I'm not too > sure how yet. For sure, adding a couple of fields on the Ada side that don't exist on the C side is highly suspicious. Better get rid of them in any case I'd think. -- Eric Botcazou
Re: ARM EABI ZCX Ada (4.6.1) almost working
On Wed, 2011-10-12 at 09:09 +0200, Eric Botcazou wrote: > > On further thinking about this, I have a feeling this may have something > > to do with the Private1 field of the unwind_exception, but I'm not too > > sure how yet. > > For sure, adding a couple of fields on the Ada side that don't exist on the C > side is highly suspicious. Better get rid of them in any case I'd think. Aye, then the Ada side doesn't build. Can you see what it is I'm missing? I can't say I truly understand this code, especially that in raise-gcc.c. I do understand there are 2 phases, but I have to say the code as the documentation (even where there is docs) is still very cryptic. I'm beginning to think the whole of a-exexpr-gcc needs to be extracted into 2 distinct files, a-exexpr-gcc (normal GCC EH - as it is) and a-exexpr-gcc-arm (ARM EABI EH). Thanks, Luke.
Re: ARM EABI ZCX Ada (4.6.1) almost working
> Aye, then the Ada side doesn't build. Can you see what it is I'm > missing? You need to further adjust the Ada code (a-exexpr-gcc.adb), which is written for DWARF EH. In particular, you need to rewrite Propagate_Exception to build a proper exception for ARM EH. > I'm beginning to think the whole of a-exexpr-gcc needs to be extracted > into 2 distinct files, a-exexpr-gcc (normal GCC EH - as it is) and > a-exexpr-gcc-arm (ARM EABI EH). Probably some parts of it, yes. -- Eric Botcazou
Re: Combine Pass Behavior
> The actual problem (or maybe my misunderstanding) is that it > combines the two original insns, then does some substitutions and tries > to match the combined and transformed insn against those defined in the > machine description. If it can't find anything there it reverts > everything and proceeds with the next insn pair. It never tries out the > straight forward option in the first place (which is not to transform > the combination). The combiner pass does some form of canonicalization to better combine, see expand_compound_operation and make_compound_operation. > Is the scenario above intended behavior of the combine pass or an > accident? Or maybe even something else wrong in the machine description > that makes it behave like that? See how the i386 back-end copes with this for its "test" instruction. -- Eric Botcazou
Question on INSN_P and "real" insns
In rtl.h there is
/* Predicate yielding nonzero iff X is a real insn. */
#define INSN_P(X) \
(NONJUMP_INSN_P (X) || DEBUG_INSN_P (X) || JUMP_P (X) || CALL_P (X))
and in emit-rtl:
/* Return the last INSN, CALL_INSN or JUMP_INSN before INSN;
or 0, if there is none. This routine does not look inside
SEQUENCEs. */
rtx
prev_real_insn (rtx insn)
{
while (insn)
{
insn = PREV_INSN (insn);
if (insn == 0 || INSN_P (insn))
break;
}
return insn;
}
The question for me is now what means "real"?
>From my understanding a "real" insn is an insn that leads to code that will be
executed like INSN, CALL_INSN or JUMP_INSN but not DEBUG_INSN that's used for
location tracking or shipping debug information or CODE_LABEL or whatever.
This means that next_real_insn depends on -g? And that I have to write my own
next really_real_insn?
next_nonnote_nondebug_insn is not what I need (no CODE_LABEL etc.)
Thanks for any hints,
Johann
Re: Question on INSN_P and "real" insns
> From my understanding a "real" insn is an insn that leads to code that will > be executed like INSN, CALL_INSN or JUMP_INSN but not DEBUG_INSN that's > used for location tracking or shipping debug information or CODE_LABEL or > whatever. > > This means that next_real_insn depends on -g? And that I have to write my > own next really_real_insn? Try prev_active_insn/next_active_insn. -- Eric Botcazou
Re: Question on INSN_P and "real" insns
Eric Botcazou schrieb: >> From my understanding a "real" insn is an insn that leads to code that will >> be executed like INSN, CALL_INSN or JUMP_INSN but not DEBUG_INSN that's >> used for location tracking or shipping debug information or CODE_LABEL or >> whatever. >> >> This means that next_real_insn depends on -g? And that I have to write my >> own next really_real_insn? > > Try prev_active_insn/next_active_insn. Ahh, yes. That looks fine. :-) Thanks Eric
Re: new triplet for x32 psABI?
On Wednesday 12 October 2011 01:03:19 Michael LIAO wrote: > I am not asking a dedicated triplet for x32 to be used exclusively for > x32 package build. I am asking additional triplet with enough details > of execution environment (ABI definitely a necessary detail.) for > package which relies on triplet to tell that. At least that triplet > could be canonical and widely accepted for package really caring about > that instead of forcing all package checking compiler options. If a > package needs to support similar thing to mutlilib just like glibc, > that new triplet will simiplifies their decision. > gcc definitely is not that kind of package as it could be built to > support generate x86-64, x32 and i386 code with the same package and > need a runtime option to tell that. except that if gcc doesn't change its default ABI output, it doesn't make it terribly useful. you still need to specify the -mabi flag whenever you execute gcc, thus the tuple is just noise. -mike signature.asc Description: This is a digitally signed message part.
Re: new triplet for x32 psABI?
On Tue, Oct 11, 2011 at 10:03 PM, Michael LIAO wrote: > On Tue, Oct 11, 2011 at 9:21 PM, Mike Frysinger wrote: >> On Tuesday 11 October 2011 22:55:35 Michael LIAO wrote: >>> On Mon, Oct 3, 2011 at 3:34 PM, Mike Frysinger wrote: >>> > On Monday, October 03, 2011 18:25:46 Michael LIAO wrote: >>> >> The current scheme documented on website >>> >> (https://sites.google.com/site/x32abi/) uses the existing triplet but >>> >> specify x32 ABI through compiler/linker options. It works for most >>> >> compilers aware of that, but how other tools not handling >>> >> compiler/linker options knows the current build is targeted on a >>> >> different environment? >>> > >>> > the mips people have been using a single tuple for multiple abis (n32 and >>> > n64), and it doesn't appear to have been a blocker for them ... >>> >>> That's not true, at least to build glibc, you can use >>> 'mips64-linux-gnuabi64' to specify a n64 build and >>> ''mips64-linux-gnuabin32' for a n32 build without specifying compiler >>> option explicitly. I just figured this out from mips ports of glibc >>> from >>> http://repo.or.cz/w/glibc-ports.git/blob/HEAD:/sysdeps/mips/preconfigure, >>> where both compiler option and triplet are checked and triplet is >>> preferred if they are not match. >> >> while it is true glibc has this code, it doesn't make my statements >> incorrect: >> a single tuple works just fine with mips for multiple ABIs. if you look at >> other projects like gcc, it doesn't check this field at all. so you're still >> right where you started: you still haven't shown any cases which necessitate >> a >> dedicated tuple. > > That's why the proposed new triplet won't break existing packages as, > if they are compliant to autoconf, they should check that field with > 'gnu*' or just ignore it instead of an exact matching. > > I am not asking a dedicated triplet for x32 to be used exclusively for > x32 package build. I am asking additional triplet with enough details > of execution environment (ABI definitely a necessary detail.) for > package which relies on triplet to tell that. At least that triplet > could be canonical and widely accepted for package really caring about > that instead of forcing all package checking compiler options. If a > package needs to support similar thing to mutlilib just like glibc, > that new triplet will simiplifies their decision. > > gcc definitely is not that kind of package as it could be built to > support generate x86-64, x32 and i386 code with the same package and > need a runtime option to tell that. > I see 3 separate issues: 1. The file name of an x32 binary package needs to be marked as x32. 2. Compilers need a switch to generate x32 code. 3. We need to configure a software package for x32. Which problem are you trying to resolve? Please explain yours if it isn't covered above. -- H.J.
Re: new triplet for x32 psABI?
On Wed, Oct 12, 2011 at 12:28, H.J. Lu wrote: > 1. The file name of an x32 binary package needs to be marked as x32. i would think this would be completely a package manager issue and out of scope for any ABI project such as x32 -mike
Question about default_elf_asm_named_section function
Hello Everyone,
This email is in reference to the "default_elf_asm_named_section"
function in the varasm.c file.
This function is defined like this:
void
default_elf_asm_named_section (const char *name, unsigned int flags,
tree decl ATTRIBUTE_UNUSED)
But, inside the function, there is this if-statement:
if (HAVE_COMDAT_GROUP && (flags & SECTION_LINKONCE))
{
if (TREE_CODE (decl) == IDENTIFIER_NODE)
fprintf (asm_out_file, ",%s,comdat", IDENTIFIER_POINTER (decl));
else
fprintf (asm_out_file, ",%s,comdat",
IDENTIFIER_POINTER (DECL_COMDAT_GROUP (decl)));
}
The decl is set with "ATTRIBUTE_UNUSED" but the if-statement is using "decl."
Should we remove the attribute unused tag near the "tree decl" or is the
if-statement a deadcode that should never be ?
Thanks,
Balaji V. Iyer.
VIS2 pattern review
[ Using the UltraSparc Architecture, Draft D0.9.4, 27 Sep 2010.
I believe this is the most recent public manual. It covers
VIS1 and VIS2 but not VIS3. ]
The comment for fpmerge_vis is not correct.
I believe that the operation is representable with
(vec_select:V8QI
(vec_concat:V8QI
(match_operand:V4QI 1 ...)
(match_operand:V4QI 2 ...)
(parallel [
0 4 1 5 2 6 3 7
]))
which can be used as the basis for both of the
vec_interleave_lowv8qi
vec_interleave_highv8qi
named patterns.
--
> (define_insn "fmul8x16_vis"
> [(set (match_operand:V4HI 0 "register_operand" "=e")
> (mult:V4HI (match_operand:V4QI 1 "register_operand" "f")
>(match_operand:V4HI 2 "register_operand" "e")))]
This is invalid rtl. You need
(mult:V4HI
(zero_extend:V4HI
(match_operand:V4QI 1 ...))
(match_operand:V4HI 2 ...))
> (define_insn "fmul8x16au_vis"
> [(set (match_operand:V4HI 0 "register_operand" "=e")
> (mult:V4HI (match_operand:V4QI 1 "register_operand" "f")
>(match_operand:V2HI 2 "register_operand" "f")))]
AFAICS, this needs an unspec, like fmul8x16al.
Similarly for fmul8sux16_vis, fmuld8sux16_vis,
There's a code sample 7-1 that illustrates a 16x16 multiply:
fmul8sux16 %f0, %f1, %f2
fmul8ulx16 %f0, %f1, %f3
fpadd16%f2, %f3, %f4
This expansion ought to be available via the "mulv4hi3" named pattern.
Similarly there's a 16x16 -> 32 multiply example:
fmuld8sux16 %f0, %f1, %f2
fmuld8ulx16 %f0, %f1, %f3
fpadd32 %f2, %f3, %f4
that ought to be available via the "vec_widen_smult_{hi,lo}_v4hi"
named patterns.
--
The "movmisalign" named pattern ought be provided, utilizing the
alignaddr / faligndata insns.
--
The "vec_perm{,_const}v8qi" named patterns ought to be provided using
the bmask / bshuffle insns.
For vec_perm_constv8qi, the compaction of the input byte data to nibble
data, as input to bmask, can happen at compile-time. For vec_permv8qi,
you'll need to do this at runtime:
Considering each character as a nibble (x = garbage, . = zero):
i = input = xaxbxcxdxexfxgxh
t1 = i & 0x0f0f0f0f0f0f0f0f= .a.b.c.d.e.f.g.h
t2 = t1 >> 4= ..a.b.c.d.e.f.g.
t3 = t1 + t2= ..abbccddeeffggh
t4 = t3 & 0x00ff00ff00ff00ff= ..ab..cd..ef..gh
t5 = t4 >> 8= ab..cd..ef..
t6 = t4 + t5= ..ababcdcdefefgh
t7 = t6 & 0x= abcdefgh
t8 = t7 >> 16 = abcd
t9 = t7 + t8= abcdefgh
where that last addition can be performed by the bmask itself.
Dunno if you can come up with a more efficient sequence. Indeed,
you may want two totally separate sequences depending on whether
the original input is in fp (vector) or integer registers. Which
of course means delaying the expansion until reload.
--
The comment above cmask8<>_vis suggests an implementation of
the named "vcond<><>" patterns.
--
> (define_insn "fpadd64_vis"
> [(set (match_operand:DI 0 "register_operand" "=e")
> (plus:DI (match_operand:DI 1 "register_operand" "e")
> (match_operand:DI 2 "register_operand" "e")))]
> "TARGET_VIS3"
> "fpadd64\t%1, %2, %0")
This must be folded into the main "adddi3" pattern, like fpadd32s.
It's not recognizable otherwise. Similarly fpsub64. If these
patterns were earlier in the file you'd have noticed them breaking
the build.
--
> (define_code_iterator vis3_addsub_ss [ss_plus ss_minus])
> (define_code_attr vis3_addsub_ss_insn
> [(ss_plus "fpadds") (ss_minus "fpsubs")])
>
> (define_insn "_vis"
> [(set (match_operand:VASS 0 "register_operand" "=")
> (vis3_addsub_ss:VASS (match_operand:VASS 1 "register_operand"
> "")
> (match_operand:VASS 2 "register_operand"
> "")))]
> "TARGET_VIS3"
> "\t%1, %2, %0")
These should be exposed as "ssadd3" "sssub3".
Unfortunately, the compiler won't do anything with them yet,
but those are the canonical names for signed saturating add/sub,
and if you use those names we'll automatically use them properly
once the vectorizer is extended in the right directions.
--
Other missing vectorization patterns:
vec_init
vec_set
vec_extract
vec_extract_even
vec_extract_odd
vec_unpack{s,u}_{hi,lo}
vec_unpack{s,u}_float_{hi,lo}
vec_pack_{trunc,ssat,usat}
vec_pack_{s,u}fix_trunc
The first three should be provided any time any vector operation
is supported, if at all possible. Otherwise the compiler will
wind up dropping the data to memory to manipulate it.
The even/odd can be implemented with bshuffle. We probably ought
to handle this in the middle-end by falling back to vec_perm*,
but we currently don't. PPC and SPU could be simplified with this.
The vec_pack_trunc patt
