Geert Bosch wrote:
> On Nov 19, 2010, at 11:53, Eric Botcazou wrote:
>
>>> Yes, if all the people who want only one set of libraries agree on what
>>> that set shall be (or this can be selected with existing configure flags),
>>> this is the simplest way.
>>>
>> Yes, this can be selected
Eric Botcazou wrote:
>> How do you see this impacting the sparc-rtems target?
>>
>> We have v7/v8 with HW and SW FP multilibs now and
>> leon is important to us. :-D
>
> Note that LEON will also be available as mere default cpu, i.e. you'll be
> able
> to configure sparc-rtems --with-tune=leon.
Eric Botcazou wrote:
>> Yes, if all the people who want only one set of libraries agree on what
>> that set shall be (or this can be selected with existing configure flags),
>> this is the simplest way.
>
> Yes, this can be selected at configure time with --with-cpu and --with-float.
>
> The defa
> CONFIG_FPU_ENABLE Y/N would correspond to --with-float=hard/soft, and
> I believe setting CONFIG_IU_V8MULDIV to Y/N requires --with-cpu=V8/V7,
> is that correct? I think it would make sense to build these as multilibs,
> so the user can experiment to find out performance impacts of
> the various
>> * CONFIG_IU_MUL_LATENCY_2: Implementation options for the integer multiplier.
>> TypeImplementation issue-rate/latency
>> 2-clocks32x32 pipelined multiplier 1/2
>> 4-clocks16x16 standard multiplier 4/4
>> 5-clocks16x16 pipelined multiplier 4
> I would suggest a simple solution:
> I can have 5 --with-cpu configure possibilies:
>
> 1. single-lib explicit selection:
> - --with-cpu=sfsparcleon: v7/soft |
> - --with-cpu=sfsparcleonv8 : v8/soft |
> - --with-cpu=hfsparcleon: v7/hard |
> - --with-cpu=hfsparcleonv8 : v8/hard |
--
Eric Botcazou wrote:
>> I would suggest a simple solution:
>> I can have 5 --with-cpu configure possibilies:
>>
>> 1. single-lib explicit selection:
>> - --with-cpu=sfsparcleon: v7/soft |
>> - --with-cpu=sfsparcleonv8 : v8/soft |
>> - --with-cpu=hfsparcleon: v7/hard |
>> - --with-cpu=h
Eric Botcazou wrote:
>> CONFIG_FPU_ENABLE Y/N would correspond to --with-float=hard/soft, and
>> I believe setting CONFIG_IU_V8MULDIV to Y/N requires --with-cpu=V8/V7,
>> is that correct? I think it would make sense to build these as multilibs,
>> so the user can experiment to find out performance
Hi,
Appended is a new patch, this time against svn://gcc.gnu.org/svn/gcc/trunk.
Following the recent comments by Eric, the patch now sketches the
following setup:
If multi-lib is wanted:
configure --with-cpu=leon ... : creates multilib-dir soft|v8
combinations using [-msoft-float|-mcpu=
Hello All,
While debugging a MELT pass, I am sigsegv in debug_bb.
The culprit is check_bb_profile which starts with
if (profile_status == PROFILE_ABSENT)
return;
and we have in basic-block.h
#define profile_status (cfun->cfg->x_profile_status)
and unfortunately, my pass is a SIMPL
On Mon, Nov 22, 2010 at 4:43 PM, Basile Starynkevitch
wrote:
> Hello All,
>
> While debugging a MELT pass, I am sigsegv in debug_bb.
>
> The culprit is check_bb_profile which starts with
> if (profile_status == PROFILE_ABSENT)
> return;
> and we have in basic-block.h
> #define profile_status
On Mon, 22 Nov 2010 17:28:21 +0100
Richard Guenther wrote:
> On Mon, Nov 22, 2010 at 4:43 PM, Basile Starynkevitch
> wrote:
> > Hello All,
> >
> > While debugging a MELT pass, I am sigsegv in debug_bb.
> >
> > The culprit is check_bb_profile which starts with
> > if (profile_status == PROFILE_A
Basile Starynkevitch writes:
> or at least replacing the last
> check_bb_profile (bb, buffer->buffer->stream);
> in function dump_bb_header of gimple-pretty-print.c with
> if (cfun)
> check_bb_profile (bb, buffer->buffer->stream);
I think something like this is the way to
On Mon, Nov 22, 2010 at 12:31, Ian Lance Taylor wrote:
> Basile Starynkevitch writes:
>
>> or at least replacing the last
>> check_bb_profile (bb, buffer->buffer->stream);
>> in function dump_bb_header of gimple-pretty-print.c with
>> if (cfun)
>> check_bb_profile (bb, buff
My software implementation of SSE2 now passes all the testsuite
programs. In case anybody else ever needs this, it is here:
http://saf.bio.caltech.edu/pub/software/linux_or_unix_tools/soft_emmintrin.h
I compiled that with a target program and gprof showed
all the time in resulting binary in the
"David Mathog" writes:
> I compiled that with a target program and gprof showed
> all the time in resulting binary in the inlined functions. It ran about
> 4X slower than the SSE2 hardware version, which is about what I
> expected. So, so far so good. What I am worried about now is that
> sinc
As Ian said, you want to make your emulation inline functions
available when __SSE2__ macro is not defined so that you get the
definitions when -msse2 is not specified, but not getting them when
-msse2 is specified. In the future, gcc may be enhanced to exposed
those mm intrinsics unconditionally (
Ian Lance Taylor wrote:
> No. If I understand what you are doing, I don't think you want to use
> -msse2 at all. In fact I think you want -mno-sse2.
Following your suggestion mo-sse2 was tried, which generated an error
message well beyond my comprehension:
gcc -std=gnu99 -g -pg -pthread -O4 -D
"David Mathog" writes:
> Following your suggestion mo-sse2 was tried, which generated an error
> message well beyond my comprehension:
>
> gcc -std=gnu99 -g -pg -pthread -O4 -DSOFT_SSE2 -msse -mno-sse2
> -DHAVE_CONFIG_H -I../../easel -I../../easel -I. -I.. -I. -I../../src -o
> msvfilter.o -c ms
19 matches
Mail list logo
