On Tue, Nov 19, 2013 at 6:07 PM, Richard Biener <rguent...@suse.de> wrote:
> On Tue, 19 Nov 2013, Sergey Ostanevich wrote:
>
>> :) agree to you, but as soon as you're a user who tries to introduce
>> vector code and face a bug in cost model you'd like to have a
>> workaround until the bug will be fixed and compiler will come to you
>> with new OS distribution, don't you?
>>
>> I propose the following, yet SLP have to use a NULL as a loop info
>> which looks somewhat hacky.
>
> I think this is overengineering. -fvect-cost-model will do as
> workaround. And -fsimd-vect-cost-model has what I consider
> duplicate - "simd" and "vect".
I just wanted to separate the autovectorized loops from ones user
wants to vectorize. The -fvect-cost-model will force all at once.
That's the reason to introcude the simd-vect, since pragma name
is simd.
>
> Richard.
>
>> Sergos
>>
>>
>> * common.opt: Added new option -fsimd-vect-cost-model
>> * tree-vectorizer.h (unlimited_cost_model): Interface update
>> to rely on particular loop info
>> * tree-vect-data-refs.c (vect_peeling_hash_insert): Update to
>> unlimited_cost_model call according to new interface
>> (vect_peeling_hash_choose_best_peeling): Ditto
>> (vect_enhance_data_refs_alignment): Ditto
>> * tree-vect-slp.c: Ditto
>> * tree-vect-loop.c (vect_estimate_min_profitable_iters): Ditto
>> plus issue a warning in case cost model overrides users' directive
>>
>>
>>
>> diff --git a/gcc/common.opt b/gcc/common.opt
>> index d5971df..87b3b37 100644
>> --- a/gcc/common.opt
>> +++ b/gcc/common.opt
>> @@ -2296,6 +2296,10 @@ fvect-cost-model=
>> Common Joined RejectNegative Enum(vect_cost_model)
>> Var(flag_vect_cost_model) Init(VECT_COST_MODEL_DEFAULT)
>> Specifies the cost model for vectorization
>>
>> +fsimd-vect-cost-model=
>> +Common Joined RejectNegative Enum(vect_cost_model)
>> Var(flag_simd_vect_cost_model) Init(VECT_COST_MODEL_UNLIMITED)
>> +Specifies the cost model for vectorization in loops marked with
>> #pragma omp simd
>> +
>> Enum
>> Name(vect_cost_model) Type(enum vect_cost_model) UnknownError(unknown
>> vectorizer cost model %qs)
>>
>> diff --git a/gcc/tree-vect-data-refs.c b/gcc/tree-vect-data-refs.c
>> index 83d1f45..e26f704 100644
>> --- a/gcc/tree-vect-data-refs.c
>> +++ b/gcc/tree-vect-data-refs.c
>> @@ -1090,7 +1090,8 @@ vect_peeling_hash_insert (loop_vec_info
>> loop_vinfo, struct data_reference *dr,
>> *new_slot = slot;
>> }
>>
>> - if (!supportable_dr_alignment && unlimited_cost_model ())
>> + if (!supportable_dr_alignment
>> + && unlimited_cost_model (LOOP_VINFO_LOOP (loop_vinfo)))
>> slot->count += VECT_MAX_COST;
>> }
>>
>> @@ -1200,7 +1201,7 @@ vect_peeling_hash_choose_best_peeling
>> (loop_vec_info loop_vinfo,
>> res.peel_info.dr = NULL;
>> res.body_cost_vec = stmt_vector_for_cost ();
>>
>> - if (!unlimited_cost_model ())
>> + if (!unlimited_cost_model (LOOP_VINFO_LOOP (loop_vinfo)))
>> {
>> res.inside_cost = INT_MAX;
>> res.outside_cost = INT_MAX;
>> @@ -1429,7 +1430,7 @@ vect_enhance_data_refs_alignment (loop_vec_info
>> loop_vinfo)
>> vectorization factor.
>> We do this automtically for cost model, since we
>> calculate cost
>> for every peeling option. */
>> - if (unlimited_cost_model ())
>> + if (unlimited_cost_model (LOOP_VINFO_LOOP (loop_vinfo)))
>> possible_npeel_number = vf /nelements;
>>
>> /* Handle the aligned case. We may decide to align some other
>> @@ -1437,7 +1438,7 @@ vect_enhance_data_refs_alignment (loop_vec_info
>> loop_vinfo)
>> if (DR_MISALIGNMENT (dr) == 0)
>> {
>> npeel_tmp = 0;
>> - if (unlimited_cost_model ())
>> + if (unlimited_cost_model (LOOP_VINFO_LOOP (loop_vinfo)))
>> possible_npeel_number++;
>> }
>>
>> diff --git a/gcc/tree-vect-loop.c b/gcc/tree-vect-loop.c
>> index 86ebbd2..be66172 100644
>> --- a/gcc/tree-vect-loop.c
>> +++ b/gcc/tree-vect-loop.c
>> @@ -2696,7 +2696,7 @@ vect_estimate_min_profitable_iters
>> (loop_vec_info loop_vinfo,
>> void *target_cost_data = LOOP_VINFO_TARGET_COST_DATA (loop_vinfo);
>>
>> /* Cost model disabled. */
>> - if (unlimited_cost_model ())
>> + if (unlimited_cost_model (LOOP_VINFO_LOOP (loop_vinfo)))
>> {
>> dump_printf_loc (MSG_NOTE, vect_location, "cost model disabled.\n");
>> *ret_min_profitable_niters = 0;
>> @@ -2929,6 +2929,11 @@ vect_estimate_min_profitable_iters
>> (loop_vec_info loop_vinfo,
>> /* vector version will never be profitable. */
>> else
>> {
>> + if (LOOP_VINFO_LOOP (loop_vinfo)->force_vect)
>> + {
>> + pedwarn (vect_location, 0, "Vectorization did not happen
>> for the loop");
>> + }
>> +
>> if (dump_enabled_p ())
>> dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
>> "cost model: the vector iteration cost = %d "
>> diff --git a/gcc/tree-vect-slp.c b/gcc/tree-vect-slp.c
>> index 247bdfd..4b25964 100644
>> --- a/gcc/tree-vect-slp.c
>> +++ b/gcc/tree-vect-slp.c
>> @@ -2171,7 +2171,7 @@ vect_slp_analyze_bb_1 (basic_block bb)
>> }
>>
>> /* Cost model: check if the vectorization is worthwhile. */
>> - if (!unlimited_cost_model ()
>> + if (!unlimited_cost_model (NULL)
>> && !vect_bb_vectorization_profitable_p (bb_vinfo))
>> {
>> if (dump_enabled_p ())
>> diff --git a/gcc/tree-vectorizer.h b/gcc/tree-vectorizer.h
>> index a6c5b59..2916906 100644
>> --- a/gcc/tree-vectorizer.h
>> +++ b/gcc/tree-vectorizer.h
>> @@ -919,9 +919,12 @@ known_alignment_for_access_p (struct
>> data_reference *data_ref_info)
>>
>> /* Return true if the vect cost model is unlimited. */
>> static inline bool
>> -unlimited_cost_model ()
>> +unlimited_cost_model (loop_p loop)
>> {
>> - return flag_vect_cost_model == VECT_COST_MODEL_UNLIMITED;
>> + return (flag_vect_cost_model == VECT_COST_MODEL_UNLIMITED
>> + || (loop != NULL
>> + && loop->force_vect
>> + && flag_simd_vect_cost_model == VECT_COST_MODEL_UNLIMITED));
>> }
>>
>> /* Source location */
>>
>> On Mon, Nov 18, 2013 at 7:13 PM, Richard Biener <rguent...@suse.de> wrote:
>> > On Mon, 18 Nov 2013, Sergey Ostanevich wrote:
>> >
>> >> I would agree that the example is just for the case cost model makes
>> >> correct estimation But how can we assure ourself that it won't have any
>> >> mistakes in the future?
>> >
>> > We call it bugs and not mistakes and we have bugzilla for it.
>> >
>> > Richard.
>> >
>> >> I believe it'll be Ok to introduce an extra flag as Jakub proposed for the
>> >> dedicated simd-forced vectorization to use unlimited cost model. This
>> >> can be default for -fopenmp or there should be a warning issued that
>> >> compiler overrides user's request of vectorization. In such a case user
>> >> can enforce vectorization (even with mentioned results :) with this
>> >> unlimited cost model for simd.
>> >>
>> >>
>> >>
>> >> On Fri, Nov 15, 2013 at 6:24 PM, Richard Biener <rguent...@suse.de> wrote:
>> >> > On Fri, 15 Nov 2013, Sergey Ostanevich wrote:
>> >> >
>> >> >> Richard,
>> >> >>
>> >> >> here's an example that causes trigger for the cost model.
>> >> >
>> >> > I hardly believe that (AVX2)
>> >> >
>> >> > .L9:
>> >> > vmovups (%rsi), %xmm3
>> >> > addl $1, %r8d
>> >> > addq $256, %rsi
>> >> > vinsertf128 $0x1, -240(%rsi), %ymm3, %ymm1
>> >> > vmovups -224(%rsi), %xmm3
>> >> > vinsertf128 $0x1, -208(%rsi), %ymm3, %ymm3
>> >> > vshufps $136, %ymm3, %ymm1, %ymm3
>> >> > vperm2f128 $3, %ymm3, %ymm3, %ymm2
>> >> > vshufps $68, %ymm2, %ymm3, %ymm1
>> >> > vshufps $238, %ymm2, %ymm3, %ymm2
>> >> > vmovups -192(%rsi), %xmm3
>> >> > vinsertf128 $1, %xmm2, %ymm1, %ymm2
>> >> > vinsertf128 $0x1, -176(%rsi), %ymm3, %ymm1
>> >> > vmovups -160(%rsi), %xmm3
>> >> > vinsertf128 $0x1, -144(%rsi), %ymm3, %ymm3
>> >> > vshufps $136, %ymm3, %ymm1, %ymm3
>> >> > vperm2f128 $3, %ymm3, %ymm3, %ymm1
>> >> > vshufps $68, %ymm1, %ymm3, %ymm4
>> >> > vshufps $238, %ymm1, %ymm3, %ymm1
>> >> > vmovups -128(%rsi), %xmm3
>> >> > vinsertf128 $1, %xmm1, %ymm4, %ymm1
>> >> > vshufps $136, %ymm1, %ymm2, %ymm1
>> >> > vperm2f128 $3, %ymm1, %ymm1, %ymm2
>> >> > vshufps $68, %ymm2, %ymm1, %ymm4
>> >> > vshufps $238, %ymm2, %ymm1, %ymm2
>> >> > vinsertf128 $0x1, -112(%rsi), %ymm3, %ymm1
>> >> > vmovups -96(%rsi), %xmm3
>> >> > vinsertf128 $1, %xmm2, %ymm4, %ymm4
>> >> > vinsertf128 $0x1, -80(%rsi), %ymm3, %ymm3
>> >> > vshufps $136, %ymm3, %ymm1, %ymm3
>> >> > vperm2f128 $3, %ymm3, %ymm3, %ymm2
>> >> > vshufps $68, %ymm2, %ymm3, %ymm1
>> >> > vshufps $238, %ymm2, %ymm3, %ymm2
>> >> > vmovups -64(%rsi), %xmm3
>> >> > vinsertf128 $1, %xmm2, %ymm1, %ymm2
>> >> > vinsertf128 $0x1, -48(%rsi), %ymm3, %ymm1
>> >> > vmovups -32(%rsi), %xmm3
>> >> > vinsertf128 $0x1, -16(%rsi), %ymm3, %ymm3
>> >> > cmpl %r8d, %edi
>> >> > vshufps $136, %ymm3, %ymm1, %ymm3
>> >> > vperm2f128 $3, %ymm3, %ymm3, %ymm1
>> >> > vshufps $68, %ymm1, %ymm3, %ymm5
>> >> > vshufps $238, %ymm1, %ymm3, %ymm1
>> >> > vinsertf128 $1, %xmm1, %ymm5, %ymm1
>> >> > vshufps $136, %ymm1, %ymm2, %ymm1
>> >> > vperm2f128 $3, %ymm1, %ymm1, %ymm2
>> >> > vshufps $68, %ymm2, %ymm1, %ymm3
>> >> > vshufps $238, %ymm2, %ymm1, %ymm2
>> >> > vinsertf128 $1, %xmm2, %ymm3, %ymm1
>> >> > vshufps $136, %ymm1, %ymm4, %ymm1
>> >> > vperm2f128 $3, %ymm1, %ymm1, %ymm2
>> >> > vshufps $68, %ymm2, %ymm1, %ymm3
>> >> > vshufps $238, %ymm2, %ymm1, %ymm2
>> >> > vinsertf128 $1, %xmm2, %ymm3, %ymm2
>> >> > vaddps %ymm2, %ymm0, %ymm0
>> >> > ja .L9
>> >> >
>> >> > is more efficient than
>> >> >
>> >> > .L3:
>> >> > vaddss (%rcx,%rax), %xmm0, %xmm0
>> >> > addq $32, %rax
>> >> > cmpq %rdx, %rax
>> >> > jne .L3
>> >> >
>> >> > ;)
>> >> >
>> >> >> As soon as
>> >> >> elemental functions will appear and we update the vectorizer so it can
>> >> >> accept
>> >> >> an elemental function inside the loop - we will have the same
>> >> >> situation as we have
>> >> >> it now: cost model will bail out with profitability estimation.
>> >> >
>> >> > Yes.
>> >> >
>> >> >> Still we have no chance to get info on how efficient the bar()
>> >> >> function when it
>> >> >> is in vector form.
>> >> >
>> >> > Well I assume you mean that the speedup when vectorizing the elemental
>> >> > will offset whatever wreckage we cause with vectorizing the rest of the
>> >> > statements. I'd say you can at least compare to unrolling by
>> >> > the vectorization factor, building the vector inputs to the elemental
>> >> > from scalars, distributing the vector result from the elemental to
>> >> > scalars.
>> >> >
>> >> >> I believe I should repeat: #pragma omp simd is intended for
>> >> >> introduction of an
>> >> >> instruction-level parallel region on developer's request, hence should
>> >> >> be treated
>> >> >> in same manner as #pragma omp parallel. Vectorizer cost model is an
>> >> >> obstacle
>> >> >> here, not a help.
>> >> >
>> >> > Surely not if there isn't an elemental call in it. With it the
>> >> > cost model of course will have not enough information to decide.
>> >> >
>> >> > But still, what's the difference to the case where we cannot vectorize
>> >> > the function? What happens if we cannot vectorize the elemental?
>> >> > Do we have to build scalar versions for all possible vector sizes?
>> >> >
>> >> > Richard.
>> >> >
>> >> >> Regards,
>> >> >> Sergos
>> >> >>
>> >> >>
>> >> >> On Fri, Nov 15, 2013 at 1:08 AM, Richard Biener <rguent...@suse.de>
>> >> >> wrote:
>> >> >> > Sergey Ostanevich <sergos....@gmail.com> wrote:
>> >> >> >>this is only for the whole file? I mean to have a particular loop
>> >> >> >>vectorized in a
>> >> >> >>file while all others - up to compiler's cost model. is there such a
>> >> >> >>machinery?
>> >> >> >
>> >> >> > No, there is not.
>> >> >> >
>> >> >> > Richard.
>> >> >> >
>> >> >> >>Sergos
>> >> >> >>
>> >> >> >>On Thu, Nov 14, 2013 at 12:39 PM, Richard Biener <rguent...@suse.de>
>> >> >> >>wrote:
>> >> >> >>> On Wed, 13 Nov 2013, Sergey Ostanevich wrote:
>> >> >> >>>
>> >> >> >>>> I will get some tests.
>> >> >> >>>> As for cost analysis - simply consider the pragma as a request to
>> >> >> >>>> vectorize. How can I - as a developer - enforce it beyond the
>> >> >> >>pragma?
>> >> >> >>>
>> >> >> >>> You can disable the cost model via -fvect-cost-model=unlimited
>> >> >> >>>
>> >> >> >>> Richard.
>> >> >> >>>
>> >> >> >>>> On Wed, Nov 13, 2013 at 12:55 PM, Richard Biener
>> >> >> >>>> <rguent...@suse.de>
>> >> >> >>wrote:
>> >> >> >>>> > On Tue, 12 Nov 2013, Sergey Ostanevich wrote:
>> >> >> >>>> >
>> >> >> >>>> >> The reason patch was in its original state is because we want
>> >> >> >>>> >> to notify user that his assumption of profitability may be
>> >> >> >>>> >> wrong.
>> >> >> >>>> >> This is not a part of any spec and as far as I know ICC does
>> >> >> >>>> >> not
>> >> >> >>>> >> notify user about the case. Still it can be a good hint for
>> >> >> >>>> >> those
>> >> >> >>>> >> users who tries to get as much as possible performance.
>> >> >> >>>> >>
>> >> >> >>>> >> Richard's comment on the vectorization problems is about the
>> >> >> >>>> >> same
>> >> >> >>-
>> >> >> >>>> >> to inform user that his attempt to force vectorization is
>> >> >> >>>> >> failed.
>> >> >> >>>> >>
>> >> >> >>>> >> As for profitable or not - sometimes I believe it's impossible
>> >> >> >>>> >> to
>> >> >> >>be
>> >> >> >>>> >> precise. For OMP we have case of a vector version of a function
>> >> >> >>>> >> and we have no chance to figure out whether it is profitable to
>> >> >> >>use
>> >> >> >>>> >> it or to loose it. If we can't map the loop for any vector
>> >> >> >>>> >> length
>> >> >> >>>> >> other than 1 - I believe in this case we have to bail out and
>> >> >> >>report.
>> >> >> >>>> >> Is it about 'never profitable'?
>> >> >> >>>> >
>> >> >> >>>> > For example. I think we should report non-vectorized loops
>> >> >> >>>> > that are marked with force_vect anyway, with
>> >> >> >>-Wdisabled-optimization.
>> >> >> >>>> > Another case is that a loop may be profitable to vectorize if
>> >> >> >>>> > the ISA supports a gather instruction but otherwise not. Or if
>> >> >> >>the
>> >> >> >>>> > ISA supports efficient vector construction from N not loop
>> >> >> >>>> > invariant scalars (for vectorization of strided loads).
>> >> >> >>>> >
>> >> >> >>>> > Simply disregarding all of the cost analysis sounds completely
>> >> >> >>>> > bogus to me.
>> >> >> >>>> >
>> >> >> >>>> > I'd simply go for the diagnostic for now, not changing anything
>> >> >> >>else.
>> >> >> >>>> > We want to have a good understanding about why the cost model is
>> >> >> >>>> > so bad that we have to force to ignore it for #pragma simd -
>> >> >> >>>> > thus
>> >> >> >>we
>> >> >> >>>> > want testcases.
>> >> >> >>>> >
>> >> >> >>>> > Richard.
>> >> >> >>>> >
>> >> >> >>>> >>
>> >> >> >>>> >> On Tue, Nov 12, 2013 at 6:35 PM, Richard Biener
>> >> >> >><rguent...@suse.de> wrote:
>> >> >> >>>> >> > On 11/12/13 3:16 PM, Jakub Jelinek wrote:
>> >> >> >>>> >> >> On Tue, Nov 12, 2013 at 05:46:14PM +0400, Sergey Ostanevich
>> >> >> >>wrote:
>> >> >> >>>> >> >>> ivdep just substitutes all cross-iteration data analysis,
>> >> >> >>>> >> >>> nothing related to cost model. ICC does not cancel its
>> >> >> >>>> >> >>> cost model in case of #pragma ivdep
>> >> >> >>>> >> >>>
>> >> >> >>>> >> >>> as for the safelen - OMP standart treats it as a limitation
>> >> >> >>>> >> >>> for the vector length. this means if no safelen is present
>> >> >> >>>> >> >>> an arbitrary vector length can be used.
>> >> >> >>>> >> >>
>> >> >> >>>> >> >> I was talking about GCC loop->safelen, which is INT_MAX for
>> >> >> >>#pragma omp simd
>> >> >> >>>> >> >> without safelen clause or #pragma simd without vectorlength
>> >> >> >>clause.
>> >> >> >>>> >> >>
>> >> >> >>>> >> >>> so I believe loop->force_vect is the only trigger to
>> >> >> >>disregard
>> >> >> >>>> >> >>> the cost model
>> >> >> >>>> >> >>
>> >> >> >>>> >> >> Anyway, in that case I think the originally posted patch is
>> >> >> >>wrong,
>> >> >> >>>> >> >> if we want to treat force_vect as disregard all the cost
>> >> >> >>>> >> >> model
>> >> >> >>and
>> >> >> >>>> >> >> force vectorization (well, the name of the field already
>> >> >> >>>> >> >> kind
>> >> >> >>of suggest
>> >> >> >>>> >> >> that), then IMHO we should treat it the same as
>> >> >> >>-fvect-cost-model=unlimited
>> >> >> >>>> >> >> for those loops.
>> >> >> >>>> >> >
>> >> >> >>>> >> > Err - the user may have a specific sub-architecture in mind
>> >> >> >>when using
>> >> >> >>>> >> > #pragma simd, if you say we should completely ignore the cost
>> >> >> >>model
>> >> >> >>>> >> > then should we also sorry () if we cannot vectorize the loop
>> >> >> >>(either
>> >> >> >>>> >> > because of GCC deficiencies or lack of sub-target support)?
>> >> >> >>>> >> >
>> >> >> >>>> >> > That said, at least in the cases that the cost model says the
>> >> >> >>loop
>> >> >> >>>> >> > is never profitable to vectorize we should follow its advice.
>> >> >> >>>> >> >
>> >> >> >>>> >> > Richard.
>> >> >> >>>> >> >
>> >> >> >>>> >> >> Thus (untested):
>> >> >> >>>> >> >>
>> >> >> >>>> >> >> 2013-11-12 Jakub Jelinek <ja...@redhat.com>
>> >> >> >>>> >> >>
>> >> >> >>>> >> >> * tree-vect-loop.c
>> >> >> >>>> >> >> (vect_estimate_min_profitable_iters):
>> >> >> >>Use
>> >> >> >>>> >> >> unlimited cost model also for force_vect loops.
>> >> >> >>>> >> >>
>> >> >> >>>> >> >> --- gcc/tree-vect-loop.c.jj 2013-11-12 12:09:40.000000000
>> >> >> >>+0100
>> >> >> >>>> >> >> +++ gcc/tree-vect-loop.c 2013-11-12 15:11:43.821404330
>> >> >> >>+0100
>> >> >> >>>> >> >> @@ -2702,7 +2702,7 @@ vect_estimate_min_profitable_iters
>> >> >> >>>> >> >> (loop
>> >> >> >>>> >> >> void *target_cost_data = LOOP_VINFO_TARGET_COST_DATA
>> >> >> >>(loop_vinfo);
>> >> >> >>>> >> >>
>> >> >> >>>> >> >> /* Cost model disabled. */
>> >> >> >>>> >> >> - if (unlimited_cost_model ())
>> >> >> >>>> >> >> + if (unlimited_cost_model () || LOOP_VINFO_LOOP
>> >> >> >>(loop_vinfo)->force_vect)
>> >> >> >>>> >> >> {
>> >> >> >>>> >> >> dump_printf_loc (MSG_NOTE, vect_location, "cost model
>> >> >> >>disabled.\n");
>> >> >> >>>> >> >> *ret_min_profitable_niters = 0;
>> >> >> >>>> >> >>
>> >> >> >>>> >> >> Jakub
>> >> >> >>>> >> >>
>> >> >> >>>> >> >
>> >> >> >>>> >>
>> >> >> >>>> >>
>> >> >> >>>> >
>> >> >> >>>> > --
>> >> >> >>>> > Richard Biener <rguent...@suse.de>
>> >> >> >>>> > SUSE / SUSE Labs
>> >> >> >>>> > SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
>> >> >> >>>> > GF: Jeff Hawn, Jennifer Guild, Felix Imend
>> >> >> >>>>
>> >> >> >>>>
>> >> >> >>>
>> >> >> >>> --
>> >> >> >>> Richard Biener <rguent...@suse.de>
>> >> >> >>> SUSE / SUSE Labs
>> >> >> >>> SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
>> >> >> >>> GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
>> >> >> >
>> >> >> >
>> >> >>
>> >> >
>> >> > --
>> >> > Richard Biener <rguent...@suse.de>
>> >> > SUSE / SUSE Labs
>> >> > SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
>> >> > GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
>> >>
>> >>
>> >
>> > --
>> > Richard Biener <rguent...@suse.de>
>> > SUSE / SUSE Labs
>> > SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
>> > GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
>>
>>
>
> --
> Richard Biener <rguent...@suse.de>
> SUSE / SUSE Labs
> SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
> GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
