zed.
Later, the vectorizer pass is performing the vectorization - by rewritting
scalar instructions into vector instructions.
Please have a look at the paper "Polyhedral-Model Guided Loop-Nest
Auto-Vectorization".
Konrad
2011/11/15 steven su :
> Hi,
> Can anyone explain whethe
David Miller wrote:
> From: Konrad Eisele
> Date: Tue, 01 Nov 2011 10:19:04 +0100
>
>> David Miller wrote:
>>>
>>> Please post binutils patches with the binutils development list CC:'d.
>>>
>>>
>>
>> Is the binutils developme
David Miller wrote:
>
> GCC patches are to be posted to gcc-patches, not gcc.
>
>
I have sent it there.
David Miller wrote:
>
> Please post binutils patches with the binutils development list CC:'d.
>
>
Is the binutils development list bug-binut...@gnu.org ?
Use -Aleon to enable binutils sparc-leon architecture. The leon-arch
binutils GAS has umul/smul and casa enabled.
Signed-off-by: Konrad Eisele
---
gcc/config/sparc/sparc.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc
Add -Aleon architecture selection to GAS. -Aleon supports [umul,smul] and
[casa,casl].
Signed-off-by: Konrad Eisele
---
gas/config/tc-sparc.c |3 ++-
include/opcode/sparc.h |1 +
opcodes/sparc-opc.c| 16 +---
3 files changed, 12 insertions(+), 8 deletions(-)
diff
Here are the new patches for adding -Aleon to binutils and to add -Aleon
as default asm-switch to gcc:
- [PATCH 1/1] sparc leon: add -Aleon architecture to GAS:
Binutils patch
- [PATCH 1/1] sparc leon: Use -Aleon assembler switch for -mcpu=leon arch
Gcc patch
I'll send new patches as a reply.
Eric Botcazou wrote:
> [CCing David Miller, the SPARC binutils maintainer]
> OK, so you're proposing a new 'leon' sub-architecture for binutils.
Yes.
>
>> The appended 2 patches do:
>> 1. 0001-sparc-leon-Use-Aleon-assembler-switch-for-mcpu-leon-.patch
>>Ap
Eric Botcazou wrote:
>> I just need to save it. It needs to be saved so that the FPU
>> pipeline is flushed.
>
> Then why not save it just below the stack pointer?
>
Wow, yes, that seems the right way! How simple, Thanks.
ck location for divsf3 and then define
that pattern. It does work however it feels like a hack...
-- Thanks Konrad
Like this:
;; handle divsf3
(define_expand "divsf3"
[(set (match_operand:SF 0 "register_operand" "=f")
eems I cannot use the sparc_reorg pass hook because the
stackframe might be > 4096 and a new register has to be
allocated before for the store address... Is there
some hook before the reload pass that I could use?
-- Thanks Konrad
Eric Botcazou wrote:
> So I'd suggest that Luís Vitório and/or Konrad do the required paperwork, and
> then start to post their patches on the gcc-patches@ list. I'll sponsor them
> for write access at that point.
>
Hello Eric Botcazou,
I want to once again ask for wri
re testing before installing it.
>
> What are the contributors to the patch? This is for the ChangeLog.
Contributor: "Konrad Eisele"
>
> --
> Eric Botcazou
>
>
I thought it was the old diff.
So: I'm ok with all. Thanks for the effort.
-- Greetings Konrad
* config/sparc/sparc.md (cpu attribute): Add leon.
> Include leon.md scheduling description.
> * config/sparc/leon.md: New file.
> * config/sparc/t-elf: Do not assemble Solaris startup files.
> * config/sparc/t-leon: New file.
> * config/sparc/t-leon3: Likewise.
>
>
Is the list above an indication that you are already finished with
the modifications? :-)
Can you give me a note, otherwise I'll create a new patch that implements
the scheme you suggested.
-- Greetings Konrad
the the sparc_cpu is switched to
PROCESSOR_LEON.
If this sheme is ok, i'll test it more thoroughly to check that the various
version
create the right output...
Please comment.
-- Greetings Konrad
Konrad Eisele wrote:
> Hello,
> Jiri Gaisler has now signed the FSF copyleft (it took
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
le
[ --with-cpu=sparcleonv7/sparcleonv8 | --with-float=soft/hard |
--disable-multilib ]
to configure. And add the 2 cpu types sparcleonv7,sparcleonv8 that would replace
v7/v8.
Does this sound good?
-- Greetings Konrad
> GR FPU Lite: 8/8, with FDIVS/FDIVD/FSQRTS/FSQRTD 31/57/46/57 cycles,
>> non-pipelined on same unit
I could add a tune option that would switch the processor cost struct for
FPU/FPU-lite.
-- Greetings Konrad
practical approach? It would only
require one extra file, say "gcc/sparc/config/t-leon-multilib" that
enables multilib and is included with configure when --with-cpu=leon is given.
I'll prepare a patch that provides such a setup.
-- Greetings Konrad
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.
Joern Rennecke wrote:
> Quoting Konrad Eisele :
>
>> Maybe there is a simple way to achieve both multilib and singlelib?
>
> The (short-term) simple way is to have two separate configurations.
> For a more flexible approach, look at how the SH port allows you to
> mi
e apps I dont want the need to supply the extra
switches explicitly all the time.
Maybe there is a simple way to achieve both multilib and singlelib?
>
> It turns out that we have ported GNAT (the GNU Ada compiler) to embedded LEON
> targets at AdaCore so we also have some material, mostly orthogonal to yours.
> Give me a few days to port your 4.4 patches and dig out ours, and I'll post a
> combined patch to serve as a basis for further discussions.
>
Ok, I'll wait.
-- Greetings Konrad
>the SPARC back-end of the mainline compiler. I'd be happy to review patches
>to this effect (and I presume the other SPARC maintainers are OK with this).
>
>So I'd suggest that Luís Vitório and/or Konrad do the required paperwork, and
>then start to post their patches on t
SPARC maintainers are OK
with this).
>
> So I'd suggest that Luís Vitório and/or Konrad do the required
paperwork, and
> then start to post their patches on the gcc-patches@ list. I'll
sponsor them
> for write access at that point.
This is kind news. I gladly take this o
Hi,
sorry for my top-posting in last e-mail.
> hi,
>
> they should work completely independently from vectorization. It does not
> matter if vectorizaton is already run or not, they will apply
> if You enable them by flags.
>
> konrad
>
>
> Dorit,
> So it is
hi,
they should work completely independently from vectorization. It does not
matter if vectorizaton is already run or not, they will apply
if You enable them by flags.
konrad
egards,
Konrad
2008/6/11 Cédric Bastoul <[EMAIL PROTECTED]>:
> I started to write the following message two days ago but I wished to
> send a .cloog which is not easy since I changed my laptop just before
> the trip I'm still on ! I need to finish installing all the tools...
>
28 matches
Mail list logo
