Re: debugging
On Tue, Mar 22, 2011 at 03:29:26PM -0700, Ian Lance Taylor wrote: > Mike Stump writes: > > > So, I was trying to debug some stuff with the top of the tree on a suse > > linux x86_64 box and got: > > > > (gdb) p mode > > Unhandled dwarf expression opcode 0xf3 > > > > which I don't find entertaining. I know I _could_ install a new gdb, and > > most likely this would fix the problem, but, I don't want to do that right > > now. I think gcc should avoid codes that gdb doesn't support. I rebuilt > > with --O0, just to try and avoid the issue, and that didn't work either. > > :-( At -O0 -g DW_OP_GNU_entry_value isn't emitted, you need var-tracking for it, nothing else creates it. > I haven't looked, but you should be able to use, e.g., -gdwarf-2 > -gstrict-dwarf. If that doesn't work then something has gone wrong. Even -gdwarf-3 -gstrict-dwarf or -gdwarf-4 -gstrict-dwarf or -fno-var-tracking-assignments will stop emitting them. Alternatively, new enough gdb will ignore them: http://sources.redhat.com/ml/gdb-cvs/2011-03/msg00268.html or alternatively http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval is the git branch with gdb support for this, though as I was told it is a GDB 7.4 material rather than 7.3 (the msg00268.html commit is hopefully GDB 7.3 material). Jakub
Re: RFC: Representing vector lane load/store operations
On Tue, Mar 22, 2011 at 8:43 PM, Richard Sandiford wrote: > Richard Guenther writes: >> Simple. Just make them registers anyway (I did that in the past >> when working on middle-end arrays). You'd set DECL_GIMPLE_REG_P >> on the decl. > > OK, thanks, I'll give that a go. TBH, I'm still hopeful we can > do without it, because we do seem to cope quite well as things stand. > But I suppose that might not hold true as the examples get more complicated. > >> 4. a vector-of-vectors type >> >> Cons >> * I don't think we want that ;) > > Yeah :-) > >>> __builtin_load_lanes (REF : array N*M of X) >>> returns array N of vector M of X >>> maps to vldN on ARM >>> in practice, the result would be used in assignments of the form: >>> vectorY = ARRAY_REF >>> >>> __builtin_store_lanes (VECTORS : array N of vector M of X) >>> returns array N*M of X >>> maps to vstN on ARM >>> in practice, the argument would be populated by assignments of the >>> form: >>> ARRAY_REF = vectorY >>> >>> __builtin_load_lane (REF : array N of X, >>> VECTORS : array N of vector M of X, >>> LANE : integer) >>> returns array N of vector M of X >>> maps to vldN_lane on ARM >>> >>> __builtin_store_lane (VECTORS : array N of vector M of X, >>> LANE : integer) >>> returns array N of X >>> maps to vstN_lane on ARM >>> >>> __builtin_load_dup (REF : array N of X) >>> returns array N of vector M of X >>> maps to vldN_dup on ARM >>> >>> I've hacked up a prototype of this and it seems to produce good code. >>> What do you think? >> >> How do you expect these to be used? That is, would you ever expect >> components of those large vectors/arrays be used in operations >> like add, or does the HW provide vector-lane variants for those as well? > > The individual vectors would be used for add, etc. That's what the > ARRAY_REF stuff above is supposed to be getting at. So... > >> Thus, will >> >> for (i=0; i> X[i] = Y[i] + Z[i]; >> >> result in a single add per vector lane load or a single vector lane load >> for M "unrolled" instances of (small) vector adds? If the latter then >> we have to think about indexing the vector lanes as well as allowing >> partial stores (or have a vector-lane construct operation). Representing >> vector lanes as automatic memory (with array of vector type) makes >> things easy, but eventually not very efficient. > > ...Ira would know best, but I don't think it would be used for this > kind of loop. It would be more something like: > > for (i=0; i X[i] = Y[i].red + Y[i].blue + Y[i].green; > > (not a realistic example). You'd then have: > > compoundY = __builtin_load_lanes (Y); > red = ARRAY_REF > green = ARRAY_REF > blue = ARRAY_REF > D1 = red + green > D2 = D1 + blue > MEM_REF = D2; > > My understanding is that'd we never do any operations besides ARRAY_REFs > on the compound value, and that the individual vectors would be treated > pretty much like any other. Ok, I thought it might be used to have a larger vectorization factor for loads and stores, basically make further unrolling cheaper because you don't have to duplicate the loads and stores. >> I had new tree/stmt codes for array loads/stores for middle-end arrays. >> Eventually the vector lane support can at least walk in the same direction >> that middle-end arrays would ;) > > What's the status of the middle-end array stuff? A quick search > showed up your paper, but is it still WIP, or has it already gone in? > (Showing my ignorance of tree-level stuff here. :-)) It does sound > like it'd be a good fit for these ops. Well, the work is basically suspended (though a lot of middle-end surgery that was required went in) - I was stuck on the necessity to have the Fortran frontend generate these expressions to have testing on real code (rather than constructing examples from my lame C frontend + builtins hack). ISTR porting the patch to tuples, the current patch seems to have two or three places that adjust the middle-end in order to allow aggregate typed SSA names. But as you have partial defs of the vector lane array the simplest approach is probably to not make them a register. Be prepared for some surprises during RTL expansion though ;) Richard. > Richard >
Re: Using secondary reload to reload CONST_INT?
Georg-Johann Lay writes: > 1) The internals just mention TARGET_SECONDARY_RELOAD for REG-MEM and > for REG-REG moves, no word about REG-CONST moves. So is using > secondary reloads for CONST_INT (or other consts) like outlined > above a defined use case I can rely on? Yeah, it should be. Other targets rely on this too. E.g. MIPS allows integers to be stored in FPRs as well as GPRs, but you can't load a symbolic constant directly into an FPR; it has to go through a GPR. > 2) The secondary reload hook is always called with > regclass = GENERAL_REGS, even in cases where the class > is known to be NO_LD_REGS like, e.g. when preparing arguments > for a function call. Why this? I would expect to get the smallest > available regclass. If a reg lies in LD_REGS, a secondary reload > is not needed, but how can I know if class is always GENERAL_REGS? > Is it ensured that secondary reload hook gets never called when > a constraint alternative matches, like "d,i"? As far as the last bit goes: once reload has decided that it needs to reload A into B, it's uses the secondary reload hook (and only that hook) to decide whether a secondary reload is needed. The movsi constraints only matter when reloading a pre-reload movsi instruction. I think the reason you only ever see GENERAL_REGS being passed in is because (from a quick look at avr.md) very few non-move patterns use the "d" and "l" constraints. They all seem to use the "r" constraint. Thus reloads from those instructions will use GENERAL_REGS rather than NO_LD_REGS. If you want to make reload use NO_LD_REGS for these GENERAL_REGS reloads, at least when the reloaded value is a constant, then it might be worth defining TARGET_PREFERRED_RELOAD_CLASS. > 3) What is the "unit" of sri->extra_cost? Compared to COST_N_INSNS? > Or compared to "?" constraint cost? I think it's measured in the same units as REGISTER_MOVE_COST. (2 == a simple register move). Richard
coreutils fails to compile wih GCC 4.6.0-rc2 but compile fine with
I heard you would like to release gtcc4.6.0 next week, so I quickly set up a new pass 1 from LFS. With gcc-4.6-20110205, I Manage to compile coreutils (and almost the all set of ports of NuTyX) but with this version of gcc I get stuck at coreutils in the first pass. May be it's me but I prefer to ask your opignion. Maybe have look at the logs so far: http://kiao.no-ip.info/NuTyX/logs/2011/i686/pass1/17_coreutils.log You can have the all history of what I did so far. For me its very strange, I did change much in the scripts which are doing the job: http://kiao.no-ip.info/NuTyX/git/?p=MakeNuTyX;a=summary Thierry
Re: coreutils fails to compile wih GCC 4.6.0-rc2 but compile fine with
On Wed, Mar 23, 2011 at 10:30:46AM +0100, t...@nutyx.com wrote: > I heard you would like to release gtcc4.6.0 next week, so I quickly set up > a new pass 1 from LFS. With gcc-4.6-20110205, I Manage to compile > coreutils (and almost the all set of ports of NuTyX) but with this > version of gcc I get stuck at coreutils in the first pass. May be it's me > but I prefer to ask your opignion. Maybe have look at the logs so far: > > http://kiao.no-ip.info/NuTyX/logs/2011/i686/pass1/17_coreutils.log Tbat's almost certainly a user error. The: ./configure ... --with-gmp-include=/tmp/work/src/coreutils-8.10/gmp configure: WARNING: unrecognized options: --with-gmp-include warning might hint you at the error. If you don't have gmp.h available in standard include paths, it isn't surprising the compilation fails. Nothing to do with gcc. Jakub
Re: Fw: RFC: Representing vector lane load/store operations
>> ...Ira would know best, but I don't think it would be used for this >> kind of loop. It would be more something like: >> >> for (i=0; i> X[i] = Y[i].red + Y[i].blue + Y[i].green; >> >> (not a realistic example). You'd then have: >> >> compoundY = __builtin_load_lanes (Y); >> red = ARRAY_REF >> green = ARRAY_REF >> blue = ARRAY_REF >> D1 = red + green >> D2 = D1 + blue >> MEM_REF = D2; >> >> My understanding is that'd we never do any operations besides ARRAY_REFs >> on the compound value, and that the individual vectors would be treated >> pretty much like any other. > > Ok, I thought it might be used to have a larger vectorization factor for > loads and stores, basically make further unrolling cheaper because you > don't have to duplicate the loads and stores. Right, we can do that using vld1/vst1 instructions (full load/store with N=1) and operate on up to 4 doubleword vectors in parallel. But at the moment we are concentrating on efficient support of strided memory accesses. Ira
Re: RFC: Representing vector lane load/store operations
Richard Guenther writes: > But as you have partial defs of the vector lane array the simplest > approach is probably to not make them a register. Be prepared > for some surprises during RTL expansion though ;) OK. It's there I'd like to start, specifically with: These arrays of vectors would still need to have a non-BLK mode, so that they can be stored in _rtl_ registers. But we need that anyway for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic functions is very poor. because I'd like to fix the bad code we generate for intrinsics. Thing is, this is going to be another case where the mode of a type depends on the current target. E.g. on ARM, we don't want to use a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also available. Both the mode of the vector type and the mode of the array type will therefore depend on whether Neon is enabled. I know you don't like the way we handle TYPE_MODE for vectors: #define TYPE_MODE(NODE) \ (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \ ? vector_type_mode (NODE) : (NODE)->type.mode) so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping up there as well. :-) What's the best way of handling this? Richard
Re: Target library disabling at toplevel
"Joseph S. Myers" writes: > (And why (CC to maintainer) do some CRIS and MMIX targets list Fortran > in unsupported languages? I didn't think the Fortran libraries had > any porting issues, unlike Java and Go and Ada.) For the record, builds with mipsisa64-elf fail with: libgfortran/intrinsics/time_1.h:99:1: error: static declaration of ‘localtime_r’ follows non-static declaration newlib/libc/include/time.h:61:12: note: previous declaration of ‘localtime_r’ was here This is a long-standing problem. It got stalled a while ago because of a disagreement (in my eyes anyway) about how libgloss targets should be handled. We started down the path of using -T.ld, so that they could be treated like other targets. But I preferred (and still prefer) the idea of making libgfortran handle newlib in the same way as libstdc++, or disabling libgfortran if we don't care. I think Rask Ingemann Lambertsen also had a patch that used a config.cache-style approach. Richard
Re: Target library disabling at toplevel
On Tue, Mar 22, 2011 at 6:07 PM, Ian Lance Taylor wrote: > "Joseph S. Myers" writes: > >> Why do a great many targets disable libgcj by default in the toplevel >> configure.ac? > > I believe that it's just a hack: libgcj doesn't build on the target, but > gcc/java does. Disabling libgcj lets the gcc configure/make complete in > a natural way. > > unsupported_languages is a clearly superior approach, but it postdates > many of the cases in which libgcj is added to noconfigdirs. In some cases, like for x86_64-w64-mingw (Win64), we can build gcj fine, and we intend to support a java compiler. However, at present, we cannot build libgcj because the boehm-gc in the tree is several years out of date. Once Hans, or someone else with enough skill, updates that, we can turn on libgcj. Until then, we'd like to make sure that building the compiler doesn't break. Given how out of date certain dependencies are for libgcj, I would not be surprised if other targets suffered the same fate.
Re: RFC: Representing vector lane load/store operations
On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford wrote: > Richard Guenther writes: >> But as you have partial defs of the vector lane array the simplest >> approach is probably to not make them a register. Be prepared >> for some surprises during RTL expansion though ;) > > OK. It's there I'd like to start, specifically with: > > These arrays of vectors would still need to have a non-BLK mode, > so that they can be stored in _rtl_ registers. But we need that anyway > for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic > functions is very poor. > > because I'd like to fix the bad code we generate for intrinsics. > > Thing is, this is going to be another case where the mode of a type > depends on the current target. E.g. on ARM, we don't want to use > a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also > available. Both the mode of the vector type and the mode of the > array type will therefore depend on whether Neon is enabled. > > I know you don't like the way we handle TYPE_MODE for vectors: > > #define TYPE_MODE(NODE) \ > (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \ > ? vector_type_mode (NODE) : (NODE)->type.mode) > > so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping > up there as well. :-) What's the best way of handling this? I'd say use either DECL_MODE at the point where we decide on expanding vars (setting it from a target hook), or simply ask such a hook at expansion time. That should have worked for the target atttribute stuff as well instead of dispatching in TYPE_MODE (types are global and TYPE_MODE with the target attribute depends on the context, but decls are local to the declaration context, so the mode persists and is not dependent on the attribute). Might need some surgery in places where we assume TYPE_MODE == DECL_MODE, but I suspect it's mostly around RTL expansion. Richard. > Richard >
Re: RFC: Representing vector lane load/store operations
Richard Guenther writes:
> On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
> wrote:
>> Richard Guenther writes:
>>> But as you have partial defs of the vector lane array the simplest
>>> approach is probably to not make them a register. Be prepared
>>> for some surprises during RTL expansion though ;)
>>
>> OK. It's there I'd like to start, specifically with:
>>
>> These arrays of vectors would still need to have a non-BLK mode,
>> so that they can be stored in _rtl_ registers. But we need that anyway
>> for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic
>> functions is very poor.
>>
>> because I'd like to fix the bad code we generate for intrinsics.
>>
>> Thing is, this is going to be another case where the mode of a type
>> depends on the current target. E.g. on ARM, we don't want to use
>> a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also
>> available. Both the mode of the vector type and the mode of the
>> array type will therefore depend on whether Neon is enabled.
>>
>> I know you don't like the way we handle TYPE_MODE for vectors:
>>
>> #define TYPE_MODE(NODE) \
>> (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \
>> ? vector_type_mode (NODE) : (NODE)->type.mode)
>>
>> so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping
>> up there as well. :-) What's the best way of handling this?
>
> I'd say use either DECL_MODE at the point where we decide on
> expanding vars (setting it from a target hook), or simply ask such
> a hook at expansion time. That should have worked for the target
> atttribute stuff as well instead of dispatching in TYPE_MODE (types
> are global and TYPE_MODE with the target attribute depends on
> the context, but decls are local to the declaration context, so the
> mode persists and is not dependent on the attribute). Might
> need some surgery in places where we assume TYPE_MODE == DECL_MODE,
> but I suspect it's mostly around RTL expansion.
Hmm, but if we do that, when is it correct to look at TYPE_MODE?
E.g. when expanding the new __builtin_load_lanes function described
earlier, it wouldn't be valid to base the target register's mode on
TYPE_MODE, so I suppose we'd have to call the hook instead. And if we
did revert the TYPE_MODE change for vector types, the vector optabs
would need to do the same thing. Wouldn't we just end up replacing
most/all uses of TYPE_MODE with calls to the hook? What would any
remaining uses of TYPE_MODE actually be testing?
E.g. I suppose we really ought to do the same thing for 128-bit types,
since this:
/* TODO: This isn't correct, but as logic depends at the moment on
host's instead of target's wide-integer.
If there is a target not supporting TImode, but has an 128-bit
integer-scalar register, this target check needs to be adjusted. */
if (targetm.scalar_mode_supported_p (TImode))
{
int128_integer_type_node = make_signed_type (128);
int128_unsigned_type_node = make_unsigned_type (128);
}
seems to apply one value of scalar_mode_supported_p to the whole compilation.
(TImode support seems to depend on TARGET_ZARCH for s390.)
Richard
Re: Cross compiler build instructions - PowerPC
On Wed, 23 Mar 2011, Rohit Arul Raj wrote: > Hello All, > > I have been trying to build a cross compiler (for PowerPC) on x86_64 > linux host. I followed the build procedure given in the link below: > > http://www.eglibc.org/archives/patches/msg00078.html You should be referring to the current checked-in version of this documentation, not a four-year-old draft. However, it doesn't appear to have relevant changes. Maxim, perhaps we should add --disable-decimal-float --disable-libffi --disable-libquadmath to the configure options for the first GCC in EGLIBC.cross-building? -- Joseph S. Myers jos...@codesourcery.com
Re: RFC: Representing vector lane load/store operations
On Wed, Mar 23, 2011 at 1:18 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>> On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
>> wrote:
>>> Richard Guenther writes:
But as you have partial defs of the vector lane array the simplest
approach is probably to not make them a register. Be prepared
for some surprises during RTL expansion though ;)
>>>
>>> OK. It's there I'd like to start, specifically with:
>>>
>>> These arrays of vectors would still need to have a non-BLK mode,
>>> so that they can be stored in _rtl_ registers. But we need that anyway
>>> for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic
>>> functions is very poor.
>>>
>>> because I'd like to fix the bad code we generate for intrinsics.
>>>
>>> Thing is, this is going to be another case where the mode of a type
>>> depends on the current target. E.g. on ARM, we don't want to use
>>> a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also
>>> available. Both the mode of the vector type and the mode of the
>>> array type will therefore depend on whether Neon is enabled.
>>>
>>> I know you don't like the way we handle TYPE_MODE for vectors:
>>>
>>> #define TYPE_MODE(NODE) \
>>> (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \
>>> ? vector_type_mode (NODE) : (NODE)->type.mode)
>>>
>>> so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping
>>> up there as well. :-) What's the best way of handling this?
>>
>> I'd say use either DECL_MODE at the point where we decide on
>> expanding vars (setting it from a target hook), or simply ask such
>> a hook at expansion time. That should have worked for the target
>> atttribute stuff as well instead of dispatching in TYPE_MODE (types
>> are global and TYPE_MODE with the target attribute depends on
>> the context, but decls are local to the declaration context, so the
>> mode persists and is not dependent on the attribute). Might
>> need some surgery in places where we assume TYPE_MODE == DECL_MODE,
>> but I suspect it's mostly around RTL expansion.
>
> Hmm, but if we do that, when is it correct to look at TYPE_MODE?
Most of the tree passes shouldn't care about TYPE_MODE (nor
DECL_MODE) and on RTL we shouldn't need to care about trees.
> E.g. when expanding the new __builtin_load_lanes function described
> earlier, it wouldn't be valid to base the target register's mode on
> TYPE_MODE, so I suppose we'd have to call the hook instead.
Well, you'd expand __builtin_load_lanes only if the mode is available, no?
So you know the mode in advance and don't need to get it from anywhere.
> And if we
> did revert the TYPE_MODE change for vector types, the vector optabs
> would need to do the same thing. Wouldn't we just end up replacing
> most/all uses of TYPE_MODE with calls to the hook? What would any
> remaining uses of TYPE_MODE actually be testing?
I think a lot of TYPE_MODE users are just lazy, like the optabs should
get a mode input and not use a type - the vectorizer knows what target
support it targets for so it can supply a proper mode. Alternatively
extract the mode from the operands instead, using DECL_MODE.
That said, I think given that target support can change across functions
using something global like TYPE_MODE is fundamentally flawed
(unless you start doing ugly things like that callback in the TYPE_MODE
implementation).
> E.g. I suppose we really ought to do the same thing for 128-bit types,
> since this:
>
> /* TODO: This isn't correct, but as logic depends at the moment on
> host's instead of target's wide-integer.
> If there is a target not supporting TImode, but has an 128-bit
> integer-scalar register, this target check needs to be adjusted. */
> if (targetm.scalar_mode_supported_p (TImode))
> {
> int128_integer_type_node = make_signed_type (128);
> int128_unsigned_type_node = make_unsigned_type (128);
> }
>
> seems to apply one value of scalar_mode_supported_p to the whole compilation.
> (TImode support seems to depend on TARGET_ZARCH for s390.)
Well, it depends on where int128_integer_type_node is used. I think
if the target with some settings supports TImode then we probably
want to have that type node. At the point the user declares some vars
with it you can error out dependent on local support. At expansion
time you'd need to check whether accesses in a given mode are
really "possible" and dispatch to BLKmode handling if they are not.
The tree level really doesn't care, and most TYPE_MODE uses there
are bogus - the valid ones want to check targetm._mode_supported_p
instead. During RTL expansion we have to deal with handling modes
we don't support (or ICE, as we do now with a lot of target attribute
uses).
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
Richard.
Re: RFC: Representing vector lane load/store operations
Richard Guenther writes:
>> Hmm, but if we do that, when is it correct to look at TYPE_MODE?
>
> Most of the tree passes shouldn't care about TYPE_MODE (nor
> DECL_MODE) and on RTL we shouldn't need to care about trees.
It sounds like you think it would be better to get rid of TYPE_MODE.
I can see why that's appealing, but it also sounds very ambitious :-)
As well as all the uses in the middle-end, targets have (wrongly) tended
to use type modes to define the ABI. It might be quite difficult to
untangle the whole mess now.
Of course, that's also an argument in favour of what you say about
TYPE_MODE not changing unless we can help it...
> For your case in question the vectorizer would create local vars with
> that mode, knowing it is supported, so I don't see big problems for
> that particular case.
The problem is that I'd like to use this for intrinsics as well as for
automatic vectorisation. E.g. I'd like:
typedef struct int8x16x4_t
{
int8x16_t val[4];
} int8x16x4_t;
to have non-BLKmode as well. arm_neon.h uses this type of structure
to represent compounds vectors. But once the type is defined (with Neon
support enabled), there's nothing to stop someone using the type
(not the intrinsics) in a function that has Neon disabled. We mustn't
use the special mode in such cases, because there aren't enough GPRs to
store it. It should be treated as BLKmode instead. Which I suppose
is the same situation as...
> > E.g. I suppose we really ought to do the same thing for 128-bit types,
> > since this:
> >
> > /* TODO: This isn't correct, but as logic depends at the moment on
> > host's instead of target's wide-integer.
> > If there is a target not supporting TImode, but has an 128-bit
> > integer-scalar register, this target check needs to be adjusted. */
> > if (targetm.scalar_mode_supported_p (TImode))
> > {
> > int128_integer_type_node = make_signed_type (128);
> > int128_unsigned_type_node = make_unsigned_type (128);
> > }
> >
> > seems to apply one value of scalar_mode_supported_p to the whole
> > compilation.
> > (TImode support seems to depend on TARGET_ZARCH for s390.)
>
> Well, it depends on where int128_integer_type_node is used. I think
> if the target with some settings supports TImode then we probably
> want to have that type node. At the point the user declares some vars
> with it you can error out dependent on local support. At expansion
> time you'd need to check whether accesses in a given mode are
> really "possible" and dispatch to BLKmode handling if they are not.
...this. Do you mean that we'd error for local declarations, but fall
back to BLKmode for operations on already-defined (global) declarations?
I'm just worried that might be a bit inconsistent.
Richard
Re: RFC: Representing vector lane load/store operations
On Wed, Mar 23, 2011 at 2:01 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
>>> Hmm, but if we do that, when is it correct to look at TYPE_MODE?
>>
>> Most of the tree passes shouldn't care about TYPE_MODE (nor
>> DECL_MODE) and on RTL we shouldn't need to care about trees.
>
> It sounds like you think it would be better to get rid of TYPE_MODE.
> I can see why that's appealing, but it also sounds very ambitious :-)
> As well as all the uses in the middle-end, targets have (wrongly) tended
> to use type modes to define the ABI. It might be quite difficult to
> untangle the whole mess now.
>
> Of course, that's also an argument in favour of what you say about
> TYPE_MODE not changing unless we can help it...
Indeed.
>> For your case in question the vectorizer would create local vars with
>> that mode, knowing it is supported, so I don't see big problems for
>> that particular case.
>
> The problem is that I'd like to use this for intrinsics as well as for
> automatic vectorisation. E.g. I'd like:
>
> typedef struct int8x16x4_t
> {
> int8x16_t val[4];
> } int8x16x4_t;
>
> to have non-BLKmode as well. arm_neon.h uses this type of structure
> to represent compounds vectors. But once the type is defined (with Neon
> support enabled), there's nothing to stop someone using the type
> (not the intrinsics) in a function that has Neon disabled. We mustn't
> use the special mode in such cases, because there aren't enough GPRs to
> store it. It should be treated as BLKmode instead. Which I suppose
> is the same situation as...
I'd use non-BLKmode for the above unconditionally.
>> > E.g. I suppose we really ought to do the same thing for 128-bit types,
>> > since this:
>> >
>> > /* TODO: This isn't correct, but as logic depends at the moment on
>> > host's instead of target's wide-integer.
>> > If there is a target not supporting TImode, but has an 128-bit
>> > integer-scalar register, this target check needs to be adjusted. */
>> > if (targetm.scalar_mode_supported_p (TImode))
>> > {
>> > int128_integer_type_node = make_signed_type (128);
>> > int128_unsigned_type_node = make_unsigned_type (128);
>> > }
>> >
>> > seems to apply one value of scalar_mode_supported_p to the whole
>> > compilation.
>> > (TImode support seems to depend on TARGET_ZARCH for s390.)
>>
>> Well, it depends on where int128_integer_type_node is used. I think
>> if the target with some settings supports TImode then we probably
>> want to have that type node. At the point the user declares some vars
>> with it you can error out dependent on local support. At expansion
>> time you'd need to check whether accesses in a given mode are
>> really "possible" and dispatch to BLKmode handling if they are not.
>
> ...this. Do you mean that we'd error for local declarations, but fall
> back to BLKmode for operations on already-defined (global) declarations?
> I'm just worried that might be a bit inconsistent.
I'd say if somebody writes
v4sf float_vec;
void __attribute__((target("no-sse")))
foo (void)
{
float_vec += float_vec;
}
he deserves to get a diagnostic. Thus, even for global decls I think we
can reject such uses. Complication arises whenever we do not see
a decl, like for
void foo(v4sf *x)
{
}
which we could of course reject (at function definition time) if an
unsupported type is used in this way. But the function might
not even dereference that pointer ...
That said, I think for your case in question we should set possible
target attribute issues aside (because we have those issues already).
In that case you wouldn't need to touch TYPE_MODE at all as
it would have non-BLKmode as soon as you create a vector-lane
type or decl?
And I still think that only changing DECL_MODEs based on
target attributes and not TYPE_MODEs is appealing ;)
Richard.
Re: RFC: Representing vector lane load/store operations
Richard Guenther writes:
>>> For your case in question the vectorizer would create local vars with
>>> that mode, knowing it is supported, so I don't see big problems for
>>> that particular case.
>>
>> The problem is that I'd like to use this for intrinsics as well as for
>> automatic vectorisation. E.g. I'd like:
>>
>> typedef struct int8x16x4_t
>> {
>> int8x16_t val[4];
>> } int8x16x4_t;
>>
>> to have non-BLKmode as well. arm_neon.h uses this type of structure
>> to represent compounds vectors. But once the type is defined (with Neon
>> support enabled), there's nothing to stop someone using the type
>> (not the intrinsics) in a function that has Neon disabled. We mustn't
>> use the special mode in such cases, because there aren't enough GPRs to
>> store it. It should be treated as BLKmode instead. Which I suppose
>> is the same situation as...
>
> I'd use non-BLKmode for the above unconditionally.
But without Neon, there aren't enough registers to store the structure.
Any use of the Neon mode would just lead to a reload failure. Even if
we think it's not sensible to use the type without Neon, we need a better
diagnostic than that.
So I think this mode has to be conditional in exactly the way that
vector modes are, or be subject to the same diagnostics that you
were suggesting for 128-bit types.
I was actually thinking along the lines of having a target hook such as:
array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT size)
which would return true if ELEMTYPE[SIZE] should use non-BLKmode where
possible. When it returns true, we'd pass 0 rather than 1 to this
mode_for_size_tree call (from the ARRAY_TYPE case in layout_type):
/* One-element arrays get the component type's mode. */
if (simple_cst_equal (TYPE_SIZE (type),
TYPE_SIZE (TREE_TYPE (type
SET_TYPE_MODE (type, TYPE_MODE (TREE_TYPE (type)));
else
SET_TYPE_MODE (type, mode_for_size_tree (TYPE_SIZE (type),
MODE_INT, 1));
This would have the "advantage" (as I see it) of working with the
generic vector extensions too. E.g. if a user defines their own
3-element-array-of-vector type, they would benefit from the same
handling as the Neon-specific intrinsics and the vectoriser-generated
arrays.
We still make generic vectors available when there's no underlying
hardware support, so I'd have expected these 3-element-array-of-vector
types to be available too. That's why I prefer the idea of making the
mode conditional, as for vector types, rather than rejecting uses of
the type outright.
But from this:
> I'd say if somebody writes
>
> v4sf float_vec;
>
> void __attribute__((target("no-sse")))
> foo (void)
> {
> float_vec += float_vec;
> }
>
> he deserves to get a diagnostic. Thus, even for global decls I think we
> can reject such uses. Complication arises whenever we do not see
> a decl, like for
>
> void foo(v4sf *x)
> {
> }
>
> which we could of course reject (at function definition time) if an
> unsupported type is used in this way. But the function might
> not even dereference that pointer ...
it sounds like you think there's no point supporting generic vectors
when no underlying hardware support is available.
> And I still think that only changing DECL_MODEs based on
> target attributes and not TYPE_MODEs is appealing ;)
Understood. I just think that, if we do that, we really should
get rid of TYPE_MODE (as a global property) as well, otherwise there'd
be even more chaos than there is now. And that sounds like it could
be several months' work in itself.
Richard
Re: RFC: Representing vector lane load/store operations
On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
wrote:
> Richard Guenther writes:
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
>>>
>>> The problem is that I'd like to use this for intrinsics as well as for
>>> automatic vectorisation. E.g. I'd like:
>>>
>>> typedef struct int8x16x4_t
>>> {
>>> int8x16_t val[4];
>>> } int8x16x4_t;
>>>
>>> to have non-BLKmode as well. arm_neon.h uses this type of structure
>>> to represent compounds vectors. But once the type is defined (with Neon
>>> support enabled), there's nothing to stop someone using the type
>>> (not the intrinsics) in a function that has Neon disabled. We mustn't
>>> use the special mode in such cases, because there aren't enough GPRs to
>>> store it. It should be treated as BLKmode instead. Which I suppose
>>> is the same situation as...
>>
>> I'd use non-BLKmode for the above unconditionally.
>
> But without Neon, there aren't enough registers to store the structure.
> Any use of the Neon mode would just lead to a reload failure. Even if
> we think it's not sensible to use the type without Neon, we need a better
> diagnostic than that.
>
> So I think this mode has to be conditional in exactly the way that
> vector modes are, or be subject to the same diagnostics that you
> were suggesting for 128-bit types.
>
> I was actually thinking along the lines of having a target hook such as:
>
> array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT size)
>
> which would return true if ELEMTYPE[SIZE] should use non-BLKmode where
> possible. When it returns true, we'd pass 0 rather than 1 to this
> mode_for_size_tree call (from the ARRAY_TYPE case in layout_type):
>
> /* One-element arrays get the component type's mode. */
> if (simple_cst_equal (TYPE_SIZE (type),
> TYPE_SIZE (TREE_TYPE (type
> SET_TYPE_MODE (type, TYPE_MODE (TREE_TYPE (type)));
> else
> SET_TYPE_MODE (type, mode_for_size_tree (TYPE_SIZE (type),
> MODE_INT, 1));
>
> This would have the "advantage" (as I see it) of working with the
> generic vector extensions too. E.g. if a user defines their own
> 3-element-array-of-vector type, they would benefit from the same
> handling as the Neon-specific intrinsics and the vectoriser-generated
> arrays.
So the 3-element-array-of-vector type has the vector mode of a single
element? I'm confused. I also don't see how a user could want to
have a non-BLK mode on such array types (consider them being
part of a struct - how would that affect argument passing and other
ABI details?).
> We still make generic vectors available when there's no underlying
> hardware support, so I'd have expected these 3-element-array-of-vector
> types to be available too. That's why I prefer the idea of making the
> mode conditional, as for vector types, rather than rejecting uses of
> the type outright.
>
> But from this:
>
>> I'd say if somebody writes
>>
>> v4sf float_vec;
>>
>> void __attribute__((target("no-sse")))
>> foo (void)
>> {
>> float_vec += float_vec;
>> }
>>
>> he deserves to get a diagnostic. Thus, even for global decls I think we
>> can reject such uses. Complication arises whenever we do not see
>> a decl, like for
>>
>> void foo(v4sf *x)
>> {
>> }
>>
>> which we could of course reject (at function definition time) if an
>> unsupported type is used in this way. But the function might
>> not even dereference that pointer ...
>
> it sounds like you think there's no point supporting generic vectors
> when no underlying hardware support is available.
Well, I meant if the user compiles with -msse, declares such a
global var (which means it gets V4SFmode and not BLKmode)
and then uses it in a function where he explicitly disables SSE
then something is wrong. If he declares a BLKmode global
then generic vector support will happily trigger and make it work.
I realize this is all a bit tricky and probably nobody properly designed
the target attribute stuff with all these details in mind. But now
we have to live with it ... :(
>> And I still think that only changing DECL_MODEs based on
>> target attributes and not TYPE_MODEs is appealing ;)
>
> Understood. I just think that, if we do that, we really should
> get rid of TYPE_MODE (as a global property) as well, otherwise there'd
> be even more chaos than there is now. And that sounds like it could
> be several months' work in itself.
True. But I like the idea of TYPE_MODE becoming even more "dynamic"
even less.
If it's just three element array-of-vector types you need why not expose
it via attribute((mode(xyz))) only? You could alias that mode to BLKmode
if neon is not enabled ...
Richard.
Re: RFC: Representing vector lane load/store operations
Richard Guenther writes:
> On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
> wrote:
>> Richard Guenther writes:
> For your case in question the vectorizer would create local vars with
> that mode, knowing it is supported, so I don't see big problems for
> that particular case.
The problem is that I'd like to use this for intrinsics as well as for
automatic vectorisation. E.g. I'd like:
typedef struct int8x16x4_t
{
int8x16_t val[4];
} int8x16x4_t;
to have non-BLKmode as well. arm_neon.h uses this type of structure
to represent compounds vectors. But once the type is defined (with Neon
support enabled), there's nothing to stop someone using the type
(not the intrinsics) in a function that has Neon disabled. We mustn't
use the special mode in such cases, because there aren't enough GPRs to
store it. It should be treated as BLKmode instead. Which I suppose
is the same situation as...
>>>
>>> I'd use non-BLKmode for the above unconditionally.
>>
>> But without Neon, there aren't enough registers to store the structure.
>> Any use of the Neon mode would just lead to a reload failure. Even if
>> we think it's not sensible to use the type without Neon, we need a better
>> diagnostic than that.
>>
>> So I think this mode has to be conditional in exactly the way that
>> vector modes are, or be subject to the same diagnostics that you
>> were suggesting for 128-bit types.
>>
>> I was actually thinking along the lines of having a target hook such as:
>>
>> array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT size)
>>
>> which would return true if ELEMTYPE[SIZE] should use non-BLKmode where
>> possible. When it returns true, we'd pass 0 rather than 1 to this
>> mode_for_size_tree call (from the ARRAY_TYPE case in layout_type):
>>
>> /* One-element arrays get the component type's mode. */
>> if (simple_cst_equal (TYPE_SIZE (type),
>> TYPE_SIZE (TREE_TYPE (type
>> SET_TYPE_MODE (type, TYPE_MODE (TREE_TYPE (type)));
>> else
>> SET_TYPE_MODE (type, mode_for_size_tree (TYPE_SIZE (type),
>> MODE_INT, 1));
>>
>> This would have the "advantage" (as I see it) of working with the
>> generic vector extensions too. E.g. if a user defines their own
>> 3-element-array-of-vector type, they would benefit from the same
>> handling as the Neon-specific intrinsics and the vectoriser-generated
>> arrays.
>
> So the 3-element-array-of-vector type has the vector mode of a single
> element?
No, it has a wider, non-vector mode. At the moment, ARM uses integer
modes for this, and after trying a few variations, I think that's
actually the best compromise. So the uint8x16x4_t ought to have a
64-byte integer type(!), which ARM defines as XImode:
INT_MODE (XI, 64);
> I also don't see how a user could want to have a non-BLK mode on such
> array types (consider them being part of a struct - how would that
> affect argument passing and other ABI details?).
The point is that we shouldn't use the mode for the ABI anyway. Even the
intrinsic-defined types (like uint8x16x4_t above) should be passed in
the same way as BLKmode structures would.
>>> I'd say if somebody writes
>>>
>>> v4sf float_vec;
>>>
>>> void __attribute__((target("no-sse")))
>>> foo (void)
>>> {
>>> float_vec += float_vec;
>>> }
>>>
>>> he deserves to get a diagnostic. Thus, even for global decls I think we
>>> can reject such uses. Complication arises whenever we do not see
>>> a decl, like for
>>>
>>> void foo(v4sf *x)
>>> {
>>> }
>>>
>>> which we could of course reject (at function definition time) if an
>>> unsupported type is used in this way. But the function might
>>> not even dereference that pointer ...
>>
>> it sounds like you think there's no point supporting generic vectors
>> when no underlying hardware support is available.
>
> Well, I meant if the user compiles with -msse, declares such a
> global var (which means it gets V4SFmode and not BLKmode)
> and then uses it in a function where he explicitly disables SSE
> then something is wrong. If he declares a BLKmode global
> then generic vector support will happily trigger and make it work.
Ah, OK. I'm just not sure whether, to take a MIPS example,
MIPS16 functions in a "-mno-mips16" compile should behave
differently from unannotated functions in a "-mips16" compile.
> If it's just three element array-of-vector types you need why not expose
> it via attribute((mode(xyz))) only? You could alias that mode to BLKmode
> if neon is not enabled ...
I don't think that really changes anything. Getting the non-BLK mode
on the array type seems like the easy part. The difficult part is
dealing with the fallout when the array is defined in a Neon context
and used in a non-Neon context.
Richard
[pph] Adapting LTO streaming for front end AST saving
Over at the PPH branch we are starting to re-use the LTO streaming routines to save front end trees. Clearly, there are things that need to be extended and/or replaced since LTO streaming assumes that we are in GIMPLE. However, there is a large intersection that I think can be commoned out. - ASTs do not need to concern themselves with language differences. They are generated and consumed by cc1plus, so saving language-dependent information is fine. - LTO streaming has several checks and assumptions that prevent non-gimple trees (e.g., DECL_SAVED_TREE must be NULL). I'm looking for opinions on what would be the best approach to factor out the common code. So far, I have created a layer of routines and data structures that the front end calls to manipulate PPH files. These are wrappers on top of LTO streaming that deal with all the sections, buffers and streams used by LTO. I was thinking of using langhooks to do things like checks (like the check for DECL_SAVED_TREE in lto_output_ts_decl_non_common_tree_pointers or the asserts in lto_get_common_nodes). I'm expecting that there will be other things, like handling more tree nodes in the tree streaming routines. But everything else seems to be already sufficiently flexible for our needs. Thoughts? Thanks. Diego.
Re: [pph] Adapting LTO streaming for front end AST saving
On Wed, 23 Mar 2011, Diego Novillo wrote: > Over at the PPH branch we are starting to re-use the LTO streaming > routines to save front end trees. Clearly, there are things that need > to be extended and/or replaced since LTO streaming assumes that we are > in GIMPLE. However, there is a large intersection that I think can be > commoned out. > > - ASTs do not need to concern themselves with language differences. > They are generated and consumed by cc1plus, so saving > language-dependent information is fine. > - LTO streaming has several checks and assumptions that prevent > non-gimple trees (e.g., DECL_SAVED_TREE must be NULL). > > I'm looking for opinions on what would be the best approach to factor > out the common code. So far, I have created a layer of routines and > data structures that the front end calls to manipulate PPH files. > These are wrappers on top of LTO streaming that deal with all the > sections, buffers and streams used by LTO. > > I was thinking of using langhooks to do things like checks (like the > check for DECL_SAVED_TREE in > lto_output_ts_decl_non_common_tree_pointers or the asserts in > lto_get_common_nodes). I'm expecting that there will be other things, > like handling more tree nodes in the tree streaming routines. But > everything else seems to be already sufficiently flexible for our > needs. > > Thoughts? Yes, Micha has a load of patches cleaning up streaming and removing unecessary abstraction. So, why'd you need to share any of it? I think it would be much easier if you worked with a copy (ugh, streaming trees again). Richard.
Re: [pph] Adapting LTO streaming for front end AST saving
On Wed, Mar 23, 2011 at 10:53, Richard Guenther wrote: > Yes, Micha has a load of patches cleaning up streaming and removing > unecessary abstraction. So, why'd you need to share any of it? Removing unnecessary abstraction is fine. But there is a bunch of code that will be common, in particular: building string index tables, symbol tables (the decl index), reading/writing hooks to use other file formats (pph are not elf files) and basic trees (particularly, decls, constants, expressions). We could add anything that is specific to the front end we can add with callbacks. But duplicating all that common code seems wasteful. Diego.
Re: [pph] Adapting LTO streaming for front end AST saving
> On Wed, 23 Mar 2011, Diego Novillo wrote: > > > Over at the PPH branch we are starting to re-use the LTO streaming > > routines to save front end trees. Clearly, there are things that need > > to be extended and/or replaced since LTO streaming assumes that we are > > in GIMPLE. However, there is a large intersection that I think can be > > commoned out. > > > > - ASTs do not need to concern themselves with language differences. > > They are generated and consumed by cc1plus, so saving > > language-dependent information is fine. > > - LTO streaming has several checks and assumptions that prevent > > non-gimple trees (e.g., DECL_SAVED_TREE must be NULL). > > > > I'm looking for opinions on what would be the best approach to factor > > out the common code. So far, I have created a layer of routines and > > data structures that the front end calls to manipulate PPH files. > > These are wrappers on top of LTO streaming that deal with all the > > sections, buffers and streams used by LTO. > > > > I was thinking of using langhooks to do things like checks (like the > > check for DECL_SAVED_TREE in > > lto_output_ts_decl_non_common_tree_pointers or the asserts in > > lto_get_common_nodes). I'm expecting that there will be other things, > > like handling more tree nodes in the tree streaming routines. But > > everything else seems to be already sufficiently flexible for our > > needs. > > > > Thoughts? > > Yes, Micha has a load of patches cleaning up streaming and removing > unecessary abstraction. So, why'd you need to share any of it? I Cool, I also have some. > think it would be much easier if you worked with a copy (ugh, > streaming trees again). I also think using same machinery for FE/gimple is a mistake. Trees are making life hard since they are interface in between FE<->gimplifier, part of gimple, interface for RTL expansion and way we represent debug info. Those are not neccesarily related things and tying them together makes things harder to optimize & cleanup. I would rather see well define Gimple bitcode rather than designing common format to handle PCHs, LTO and external templates on the top of existing trees. Honza > > Richard.
Re: [pph] Adapting LTO streaming for front end AST saving
On Wed, Mar 23, 2011 at 12:38, Jan Hubicka wrote: >> think it would be much easier if you worked with a copy (ugh, >> streaming trees again). > > I also think using same machinery for FE/gimple is a mistake. Trees are > making > life hard since they are interface in between FE<->gimplifier, part of gimple, > interface for RTL expansion and way we represent debug info. Yes, but this is only part of the common machinery. I'm actually more interested in the other functionality. Keeping string tables, symbol tables, file sections, ability to stream shared pointers by creating references, etc. As gimple gets rid of trees, we can transition that code into the front end. The common code that remains, we can add hooks so each user implements its own functionality. > Those are not neccesarily related things and tying them together makes > things harder to optimize & cleanup. No, that's not the intent. I simply want to re-use common code. We will have streamers for debug info, and passes have their own streamers. PPH is adding another streamer in the front end. All I'm looking for is to have a set of common streaming code I can use. > I would rather see well define Gimple bitcode rather than designing common > format to handle PCHs, LTO and external templates on the top of existing > trees. In as much as gimple is still using tree codes, those would remain in common code. As gimple gets rid of trees, we handle those in the front end. So, I don't think that will be a problem. Diego.
Re: Target library disabling at toplevel
On 03/22/2011 08:51 PM, Joseph S. Myers wrote: Why do a great many targets disable libgcj by default in the toplevel configure.ac? Because that dates to before 2004, which IIRC is when toplevel configure.ac started looking at config-lang.in files. Paolo
Re: debugging
On Wed, 23 Mar 2011 08:51:25 +0100, Jakub Jelinek wrote: > http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval > is the git branch with gdb support for this, though as I was told > it is a GDB 7.4 material rather than 7.3 (the msg00268.html > commit is hopefully GDB 7.3 material). Yes it is on HEAD, 7.3 is not yet branched, gdb-7.3 will consider 0xf3 as standard (like before the gcc patch). Discussed at: [patch] [entryval] fixup: Unhandled dwarf expression opcode 0xf3 http://sourceware.org/ml/gdb-patches/2011-03/msg00965.html GDB is now in something like "stage 3" for gdb-7.3. The full support from archer-jankratochvil-entryval will go in GDB HEAD after 7.3 gets branched/released. Thanks, Jan
Re: [pph] Adapting LTO streaming for front end AST saving
This thread spilled into IRC chatter. I think we stopped talking past each other now: (2011-03-23 12:51:34) froydnj: dnovillo: gimple gets rid of trees? how does that work? (2011-03-23 12:52:29) dnovillo: froydnj: we've been talking about tuplifying more, but i don't think it makes sense past certain point (say, _CST, IDENTIFIERS, DECLs, etc) (2011-03-23 12:53:05) dnovillo: i wasn't clear in my initial message, i think that's what confused honza and richi (2011-03-23 12:58:26) honza: dnovillo: What would be really nice to have is an sane (from middle end POV) type representation. Tree types makes life quite hard, especially at WPA time. (2011-03-23 12:58:35) honza: because they tie way too many things together (2011-03-23 12:59:03) honza: but indeed gimplified/tuplified types are quite intrusive change. (2011-03-23 12:59:18) dnovillo: honza: agreed. but i want to make sure my point is clear. i want to reuse common streaming code. it's more than just pickling trees. (2011-03-23 13:00:06) dnovillo: honza: there will be things we will never change out of trees, so that will stay in common code. if/when we start getting rid of trees in gimple, it will make sense to take that code out of lto-streamer*.c and move it into tree-streamer*c or some such. (2011-03-23 13:00:30) dnovillo: does that clarify things? (2011-03-23 13:02:53) honza: dnovillo: Well, I am trying to get cleaner idea where we want to go with streaming WRT LTO and WPA in longer term. It is obvious that gread deal of ineffecitvity coes from fact that we stream blindly all the data we currently have in our tree nodes = a lot of things that is never really used in middle-end. (2011-03-23 13:03:34) honza: plus I really think we want defined bytecode in longer run and trees makes this hard too. (2011-03-23 13:03:35) matz: honza: I'm currently working quite hard to do merging while reading in the global state, and to reduce the stuff we have to put into global state. (2011-03-23 13:03:44) dnovillo: honza: sure. and we want to get rid of as much as we can there. (2011-03-23 13:04:06) matz: But now the IPA passes are quite a road-block :/ (2011-03-23 13:04:17) dnovillo: honza: but i don't want to simply toss out that pickling code. i want to move it to tree-streamer* (2011-03-23 13:04:18) honza: matz: Why? (2011-03-23 13:04:38) dnovillo: honza: so that we can use from FEs that want to pickle trees. (2011-03-23 13:04:40) matz: honza: I managed to get quite far with merging symbols before reading in the cgraph. (2011-03-23 13:04:58) honza: matz: and now you need to merge summaries, I see ;) (2011-03-23 13:05:19) matz: honza: Exactly. And the info in those summaries is currently not always self-contained. (2011-03-23 13:05:59) honza: dnovillo: hmm, I really don't know here. On one hand clearly I would like to see more separation of gimple and frontend ASTs. on the other side with current state of affairs I see that not sharing streamer code is just impractical code duplication... (2011-03-23 13:06:02) matz: honza: For instance the ipa-prop info doesn't stream out the number of params, and also depends on the callee list at stream-in to be exactly as when streaming out. (2011-03-23 13:06:24) dnovillo: honza: now you lost me. what? (2011-03-23 13:08:11) honza: dnovillo: for LTO it makes a lot sense when the way you stream function bodies is well defined VM (well, like LLVM). We can't reach this when we will just keep saving our trees without any more strict specification (2011-03-23 13:08:38) honza: for AST in FE you have different requirements, even when they happens to be represented by same tree * structure in GCC. (2011-03-23 13:08:51) dnovillo: honza: sure. i agree with that completely. (2011-03-23 13:09:18) honza: that is flawed design. So i am just concerned that merging the streamer implemetnation still goes indirection of reusing tree for both purposes. (2011-03-23 13:09:55) dnovillo: honza: i am not talking about merging anything. i don't know how to explain this. let me try again. (2011-03-23 13:10:04) dnovillo: honza: there's a bunch of streaming code that has nothing to do with pickling. (2011-03-23 13:10:05) honza: but I guess without going all the way and designing gimple way of implementing tuples/debug info etc. there is not much help. (2011-03-23 13:10:28) dnovillo: honza: that code is commonable and re-usable from various places. (2011-03-23 13:10:30) dnovillo: right? (2011-03-23 13:10:59) honza: OK. Depends on how high level of streaming logic you think of. (2011-03-23 13:11:21) dnovillo: (keeping of string tables, streams, sections, hooks to read/write, etc) (2011-03-23 13:11:35) honza: yep, that is fine for sure. (2011-03-23 13:11:39) dnovillo: honza: the *pickling* code is what you are worried about. (2011-03-23 13:11:50) honza: OK, I guess we are in sync then :0 (2011-03-23 13:12:00) honza: Yes, getting this separated and with clean API is good idea. (2011-03-23 13:12:17) matz: And even the pickling code currently can be
-Wconversion is very poor
I've turned on all warnings to have clean program.
Turn on -Wconversion but it will not care about BIG trouble in C++:
conversion.
class A{
public:
A(unsigned int){}
};
class B{
public:
B(A){}
};
B b(-1); //OK without warnings
int main(void){}
-1 => A(FF..FF) => B(FF..FF)
I want to see all program like:
B b(A(-1));
Which warning I must to set?
--
View this message in context:
http://old.nabble.com/-Wconversion-is-very-poor-tp3197p3197.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: -Wconversion is very poor
On 23 March 2011 17:58, Lisp2D wrote:
>
> I've turned on all warnings to have clean program.
> Turn on -Wconversion but it will not care about BIG trouble in C++:
> conversion.
>
> class A{
> public:
> A(unsigned int){}
> };
>
> class B{
> public:
> B(A){}
> };
>
> B b(-1); //OK without warnings
> int main(void){}
>
>
> -1 => A(FF..FF) => B(FF..FF)
> I want to see all program like:
>
> B b(A(-1));
>
> Which warning I must to set?
Your question is inappropriate for this mailing list, questions about
using or building gcc should go to gcc-h...@gcc.gnu.org
Please take any follow up question to that list, thanks.
As clearly documented in the manual, you need -Wsign-conversion in C++
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Warning-Options.html#index-Wconversion-368
Re: Pruning for torture tests?
Hi Iain, > On Darwin, we have a number of gcc.c-torture fails reported for both ppc > and i386 which are bogus (nothing to do with gcc - but simply warning > output from a system tool). > > For dg-based tests these are pruned - I wonder if it would be worth adding > a prune capability to the torture suites? IMO this is the wrong approach. I'd like us to move away from the non-dg testsuites if at all possible. I had a quick look and it seems doable, but a complete cleanup of the testsuites is a giant task ;-) Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Pruning for torture tests?
Hi Rainer, On 23 Mar 2011, at 18:45, Rainer Orth wrote: On Darwin, we have a number of gcc.c-torture fails reported for both ppc and i386 which are bogus (nothing to do with gcc - but simply warning output from a system tool). For dg-based tests these are pruned - I wonder if it would be worth adding a prune capability to the torture suites? IMO this is the wrong approach. I'd like us to move away from the non-dg testsuites if at all possible. I personally agree... ... but when I suggested this for the (relatively small) ObjC set of torture tests, it was not greeted enthusiastically... (the problem voiced, IIRC, is of maintaining audit history of test pass/fails) ... I'd imagine that this would be amplified 100x for the other torture suites. Iain
Re: Pruning for torture tests?
Hi Iain, >> IMO this is the wrong approach. I'd like us to move away from the >> non-dg testsuites if at all possible. > > I personally agree... > > ... but when I suggested this for the (relatively small) ObjC set of > torture tests, it was not greeted enthusiastically... > > (the problem voiced, IIRC, is of maintaining audit history of test > pass/fails) indeed, and I wouldn't certainly advocate moving the tests around, just using a different dg-based driver for the torture testsuites. > ... I'd imagine that this would be amplified 100x for the other torture > suites. This would clearly be unacceptable. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Pruning for torture tests?
On Wed, 23 Mar 2011, Rainer Orth wrote: > indeed, and I wouldn't certainly advocate moving the tests around, just > using a different dg-based driver for the torture testsuites. gcc.c-torture/compile.exp was moved to using the dg driver a long time ago, moving the others (so that .x files are no longer needed, and so that people don't get confused and add dg- directives to individual tests that have no effect - PR 20567) certainly seems like a good idea. -- Joseph S. Myers jos...@codesourcery.com
GSoC participation question
Hello, My name is Nikolay Merinov, I am magistracy student at Ural State University (Russia). I hope to participate in GSoC and I am interesting in working on interprocedural data flow analysis. I would like to ask potential mentors about simple project that will help me to familiarize myself with current realisation of IPA in gcc. Thanks.
