Unfortunately, only 64-bit versions of popc and lzd exist, so I have
to play some shenanigans to make SImode and v8plus cases work. But
it's definitely worth it. I plan to tweak this stuff and perhaps also
add some explicit ffs patterns as well later.
There are only two sets of VIS3 instruction
From: Richard Henderson
Date: Thu, 06 Oct 2011 10:47:28 -0700
> You've said that POPC only operates on the full 64-bit register,
> but I see no zero-extend of the SImode input? Similarly for
> the clzsi patterns.
Thanks for catching this.
I guess if I emit the zero-extend, the compiler will e
From: Richard Henderson
Date: Thu, 06 Oct 2011 10:47:28 -0700
> You've said that POPC only operates on the full 64-bit register,
> but I see no zero-extend of the SImode input? Similarly for
> the clzsi patterns.
This addresses all of the problems you found, and also exposes the
"sub 32" to th
Committed to trunk.
gcc/
PR 50655
* configure.ac: Add .register directives to VIS3 test.
* configure: Regenerate.
gcc/testsuite/
PR 50655
* gcc.target/sparc/sparc.exp: Add vis3 target test.
* gcc.target/sparc/cmask.c: Use it.
* gcc.target
From: Eric Botcazou
Date: Tue, 11 Oct 2011 20:10:34 +0200
>> * gcc.target/sparc/sparc.exp: Add vis3 target test.
>
> This doesn't work. The code always compiles:
What does "gcc -mcpu=niagara3 -mvis" give to you for the following
source file:
long long
_vis3_fpadd64 (long
From: Eric Botcazou
Date: Tue, 11 Oct 2011 21:57:18 +0200
>> I would expect that to spit out a warning. Do I need to explicitly
>> add "-Wall", "-Wno-implicit" or similar? Similar tests in i386.exp don't
>> seem to need this and that was what I used as my template.
>
> -Wall does yield a warni
From: Eric Botcazou
Date: Tue, 11 Oct 2011 23:08:50 +0200
>> Cool, Eric could you quickly test the following? This still leaves
>> the i386.exp case issue open, it stands to reason that something like
>> -Wall is needed for those tests too.
>
> I think that we should go the i386 way. This work
From: Eric Botcazou
Date: Wed, 12 Oct 2011 00:33:43 +0200
>> I see, so we can test the code generation in the testsuite even if the
>> compiler was built against an assembler without support for the
>> instructions.
>
> At least partially, yes.
>
>> But in such a case, I'm unsure if I understan
From: Eric Botcazou
Date: Wed, 12 Oct 2011 23:08:39 +0200
>> I'm currently testing the following patch in various scenerios, I'm pretty
>> sure this is what you had in mind.
>
> Yes, this seems to go in the right direction. Don't you need to pass -mvis3
> instead of -mvis? Do you need to pass
From: David Miller
Date: Wed, 12 Oct 2011 17:14:59 -0400 (EDT)
> From: Eric Botcazou
> Date: Wed, 12 Oct 2011 23:08:39 +0200
>
>>> I'm currently testing the following patch in various scenerios, I'm pretty
>>> sure this is what you had in mind.
>
From: Richard Henderson
Date: Wed, 12 Oct 2011 15:32:46 -0700
> I suppose technically the middle-end could be improved to implement
> ashl as vashl by broadcasting the scalar, but Altivec
> is the only extant SIMD ISA that would make use of this. All of
> the others can arrange for constant shif
From: Richard Henderson
Date: Wed, 12 Oct 2011 15:49:28 -0700
> Ok, if I read the rtl correctly, you can perform a vector shift,
> where each shift count comes from the corresponding element of op2.
> But VIS has no vector shift where the shift count comes from a
> single scalar (immediate or reg
From: Eric Botcazou
Date: Thu, 29 Sep 2011 00:38:49 +0200
> [Vlad, if you have a few minutes, would you mind having a look at the couple
> of
> questions at the end of the message? Thanks in advance].
Vlad, ping?
Based upon a review of the sparc VIS support by Richard Henderson.
Committed to trunk.
gcc/
* config/sparc/sparc.md (UNSPEC_FPMERGE): Delete.
(UNSPEC_MUL16AU, UNSPEC_MUL8, UNSPEC_MUL8SU, UNSPEC_MULDSU): New
unspecs.
(fpmerge_vis): Remove inaccurate comment, repre
This is based upon suggestions from David Bremner.
Committed to trunk.
gcc/
* config/sparc/sparc.md (plusminus): New code iterator.
(plusminus_insn): New code attr.
(addv2si3, subv2si3, addv4hi3, subv4hi3, addv2hi3, subv2hi3): Merge
using plusminus and plusminus_
From: r...@redhat.com
Date: Thu, 13 Oct 2011 20:43:19 -0700
> These patches allow __builtin_shuffle to handle any vector permutation
> via optabs. It allows for a not-uncommon fallback to byte permutation
> at rtl expansion time, while leaving the tree/gimple-level permutation
> as element-based.
From: Eric Botcazou
Date: Fri, 14 Oct 2011 20:27:03 +0200
>> If you configure a biarch Linux/Sparc compiler defaulting to
>> 32-bit, but give --with-cpu= for a v9 cpu it erroneously
>> turns on 64-bit in TARGET_DEFAULT.
>
> PR target/50354 reports the breakage of the opposite case after the chan
From: Eric Botcazou
Date: Fri, 14 Oct 2011 22:31:53 +0200
>> If one wants a 32-bit default compiler, they should build for the
>> sparc-linux target. And this is absolutely trivial to make happen
>> in the environments where this is supposedly a problem.
>
> I have criticized so many times this
I verified that this matches what other Linux platforms have added
recently, and I was careful not to accidently include the TLS symbols.
In fact, this baseline file now matches powerpc-linux-gnu's precisely.
Ok for mainline and the 4.7 branch?
Thanks.
2012-03-23 David S. Miller
*
I noticed these problems while writing the Niagara4 scheduling
description.
The ultra3 scheduling bug is particularly heinous, it means all
integer ALU op reservations were essentially wrong since the
ialu and ialuX reservations matched the same exact instructions.
Commited to trunk.
gcc/
Niagara4 is a dual issue processor, but with a twist. The dual issue
pipeline is shared amongst a set of cpu threads.
So in the case that there is only one thread active, then up to two
instructions from that cpu thread can execute at a time. If multiple
threads are active, we can instead end u
From: Eric Botcazou
Date: Sat, 12 Nov 2011 09:57:04 +0100
>> Eric, it seems that most if not all of the other ELF sparc targets
>> will need something like this as well but I was only able to validate
>> Linux at the moment.
>
> Aren't all ELF targets of all architectures potentially affected?
From: Eric Botcazou
Date: Sun, 13 Nov 2011 00:26:51 +0100
>> Again, only those ELF targets which have an override for
>> ASM_GENERATE_INTERNAL_LABEL, which if you check is almost entirely
>> Sparc.
>
> We probably aren't looking at the same tree then. Alpha, IA-64, MIPS, HP-PA,
> SPARC and a f
From: Richard Guenther
Date: Mon, 14 Nov 2011 21:43:30 +0100
> On Mon, Nov 14, 2011 at 2:02 PM, Tom de Vries wrote:
>> This patch fixes the slow down in the compilation of 20001226-1.c caused by
>> -ftree-tail-merge.
...
>> ok for trunk?
>
> Ok.
Tom, thanks for working on this. And Richard,
From: Bernd Schmidt
Date: Tue, 15 Nov 2011 01:54:34 +0100
> On 11/15/11 01:43, Richard Henderson wrote:
>> On 11/14/2011 11:56 AM, Alan Modra wrote:
>>> * function.c (thread_prologue_and_epilogue_insns): Guard
>>> emitting return with single_succ_p test.
>>
>> Hmm. This looks plausible
Eric, this is just something I noticed while trying to fix the
vec_init problems last week.
I'm confident that the issue is real, however I can't point to any
real bugs that are caused by this.
Therefore I'm reluctant to commit this change.
What do you think?
gcc/
* config/sparc/sparc
From: Richard Henderson
Date: Thu, 17 Nov 2011 11:22:53 -1000
> Full sparc64-linux testing still underway; I've pushed these two
> patches to the git branch previously mentioned.
With these changes most of the libgomp atomic tests fail to build:
/home/davem/src/GIT/GCC/gcc/libgomp/testsuite/lib
From: Richard Henderson
Date: Sun, 20 Nov 2011 14:50:49 -1000
> I can't reproduce this. What's the exact cc1 command-line?
/home/davem/src/GIT/GCC/build-sparc-linux/gcc/cc1 -quiet -v -I
/home/davem/src/GIT/GCC/build-sparc-linux/sparc-unknown-linux-gnu/./libgomp -I
/home/davem/src/GIT/GCC/gcc/
From: Rainer Orth
Date: Mon, 21 Nov 2011 14:53:33 +0100
> Right now, it is only possible to clear the hardware capabilities
> completely, while the new v2 mapfile syntax supports selectively adding
> and removing capabilities. It is only available in Solaris 11 and
> Solaris 10 Update 10, though
From: Rainer Orth
Date: Mon, 21 Nov 2011 16:07:04 +0100
> The new gcc.target/sparc/vec-init-[1-3]-vis3.c tests might fail on
> Solaris 10 and 11 with Sun as on non-VIS3 capable hardware
> (e.g. UltraSPARC T2 or UltraSPARC IV) like this:
>
> ld.so.1: vec-init-1-vis3.exe: fatal: vec-init-1-vis3.ex
As discussed on gcc.
Committed to trunk.
gcc/
Revert
2011-11-16 Andreas Krebbel
PR middle-end/50325
* expmed.c (store_bit_field_1): Use extract_bit_field on big
endian targets if the source cannot be exactly covered by word
mode chunks.
---
g
From: Eric Botcazou
Date: Thu, 17 Nov 2011 22:21:32 +0100
>> Eric, this is just something I noticed while trying to fix the
>> vec_init problems last week.
>>
>> I'm confident that the issue is real, however I can't point to any
>> real bugs that are caused by this.
>>
>> Therefore I'm reluctant
From: Richard Henderson
Date: Thu, 17 Nov 2011 11:22:53 -1000
> Full sparc64-linux testing still underway; I've pushed these two
> patches to the git branch previously mentioned.
Hey Richard, after the ICE fix you made today the only test that
fails is gcc.dg/atomic-flag.c at -O0. Below is the
From: Richard Henderson
Date: Tue, 22 Nov 2011 14:36:53 -0800
> On 11/21/2011 09:21 PM, David Miller wrote:
>> Hey Richard, after the ICE fix you made today the only test that
>> fails is gcc.dg/atomic-flag.c at -O0. Below is the assembler
>> generated.
>
>
From: Richard Henderson
Date: Wed, 30 Nov 2011 08:39:44 -0800
> I've committed this sequence to mainline after re-testing on
> sparc64-linux.
I've got a regstrap running on Niagara-3, sorry for taking so long :-/
> As a follow-up, I have a patch to change the default memory model to
> TSO for a
From: Richard Henderson
Date: Wed, 30 Nov 2011 10:40:36 -0800
> On 11/30/2011 09:44 AM, David Miller wrote:
>> So one thing to consider doing is, if there is some doubt, to set
>> it explicitly to TSO in some crt code.
>
> ... easier to keep the RMO/PSO default in that case
From: Richard Henderson
Date: Wed, 30 Nov 2011 13:12:35 -0800
> On 11/30/2011 12:33 PM, David Miller wrote:
>> From: Richard Henderson
>> Date: Wed, 30 Nov 2011 10:40:36 -0800
>>
>>> On 11/30/2011 09:44 AM, David Miller wrote:
>>>> So one thing to con
I've known about this problem for a while but I just haven't gotten around to
fixing it up in the tree.
Committed to trunk.
* config/sparc/visintrin.h: Add appropriate __VIS__ cpp protection.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@182067
138bc75d-0d04-0410-961f-82ee72b054a4
--
From: Eric Botcazou
Date: Sat, 17 Dec 2011 00:37:43 +0100
> 2011-12-16 Eric Botcazou
>
> * config/sparc/sparc.md (UNSPEC_FRAME_BLOCKAGE): New constant.
> (frame_blockage): New expander.
> (frame_blockage): New instruction.
> * config/sparc/sparc.c (sparc_expand_prologu
From: Richard Henderson
Date: Fri, 27 Jan 2012 09:29:00 +1100
> Two of the patches have been posted here before; the libstdc++
> patch was approved by Benjamin.
>
> All of the patches tested on sparc64-linux, and sanity checked
> on x86_64-linux. I've cross-compiled for m68k-linux, but I've
> o
From: Richard Henderson
Date: Fri, 27 Jan 2012 09:41:10 +1100
> On 01/27/2012 09:34 AM, David Miller wrote:
>> From: Richard Henderson
>> Date: Fri, 27 Jan 2012 09:29:00 +1100
>>
>>> Two of the patches have been posted here before; the libstdc++
>>> patc
From: Eric Botcazou
Date: Mon, 30 Jan 2012 13:41:28 +0100
> I think it's the long-standing issue with word-mode paradoxical subregs of FP
> regs in 64-bit mode, which is present on both PA and SPARC. We don't have
> any
> real solution as of this writing, only kludges, so the attached patch ma
From: Eric Botcazou
Date: Sun, 12 Feb 2012 21:15:26 +0100
> + load[%o1 + OFFSET (JB_CFA)], %fp
> + cfi_def_cfa(%fp, 0)
> +#if STACK_BIAS
> + sub %fp, STACK_BIAS, %fp
> + cfi_def_cfa_offset(STACK_BIAS)
> +#endif
I think you really need to put the proper value into the %fp
From: Eric Botcazou
Date: Sun, 12 Feb 2012 21:15:26 +0100
> +static inline void
> +cpu_relax (void)
> +{
> + __asm volatile ("" : : : "memory");
> +}
We probably want to do some nop'ish thing here which will yield the
cpu thread on Niagara cpus, I'd recommend something along the lines of
"rd %c
Richard Henderson asked me to add an explanatory comments to explain
this decision.
* config/sparc/sparc.md (load_pcrel_sym): Explain why we
don't use the "rd %pc" instruction on v9 for PIC register loads.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@184422
138bc75d-0d04-0410
From: Eric Botcazou
Date: Mon, 27 Feb 2012 10:42:17 +0100
>> We probably want to do some nop'ish thing here which will yield the
>> cpu thread on Niagara cpus, I'd recommend something along the lines of
>> "rd %ccr, %g0" or "rd %y, %g0"
>
> libgomp has its own idea about cpu_relax:
>
> static i
From: Eric Botcazou
Date: Mon, 27 Feb 2012 21:41:23 +0100
> I think the issue is just how we unify the two cpu_relax implementations:
>
> static inline void
> cpu_relax (void)
> {
> #if defined __arch64__ || defined __sparc_v9__
> __asm volatile ("membar #LoadLoad" : : : "memory");
> #else
>
From: Eric Botcazou
Date: Wed, 29 Feb 2012 21:48:57 +0100
> As discussed with DaveM, this duplicates libitm's cpu_relax into libgomp.
>
> Tested on SPARC64/Linux, applied on the mainline.
Thanks for taking care of this Eric.
The bootstrap breaks in stage1 when trying to build libgcc for
multilib (this is sparc-unknown-linux with "--enable-targets=all"):
make[3]: Leaving directory `/home/davem/src/GIT/GCC/build-sparc-linux/gcc'
mkdir -p -- sparc-unknown-linux-gnu/libgcc
Checking multilib configuration for libgcc...
Co
From: Rainer Orth
Date: Thu, 09 Jun 2011 09:33:35 +0200
> Of course we do. I must have been dreaming when writing parts of this
> patch. I've now double-checked all md_unwind_header filenames, found
> just another typo, and installed the following as obvious.
Thanks.
From: Richard Henderson
Date: Sun, 19 Jun 2011 16:19:41 -0700
> * reg-notes.def (REG_CFA_WINDOW_SAVE): New.
> * dwarf2out.c (dwarf2out_frame_debug): Handle it.
> (dwarf2out_frame_debug_cfa_window_save): Rename from
> dwarf2out_window_save; make static.
> * tree.h (dw
From: Eric Botcazou
Date: Mon, 27 Jun 2011 18:11:10 +0200
> * config/sparc/sync.md (*stbar): Delete.
> (*membar_v8): New insn to implement UNSPEC_MEMBAR in SPARC-V8.
Code which cares about memory ordering etc. really has to know
the kind of cpu it is running on.
This is why atomic a
From: Geert Bosch
Date: Mon, 27 Jun 2011 19:36:06 -0400
> On Jun 27, 2011, at 19:00, David Miller wrote:
>
>> V8 can only reorder stores, that's why it only has a 'stbar'
>> instruction. I'm not so sure I agree with trying to paper over the
>> fact
From: Geert Bosch
Date: Mon, 27 Jun 2011 22:21:47 -0400
> On Jun 27, 2011, at 19:53, David Miller wrote:
>
>> Adding a ldstub here is going to be really expensive, on UltraSparc
>> that can be 36+ cycles even on a cache hit.
>
> Yes, synchronization in multi-CPU systems
From: David Miller
Date: Mon, 27 Jun 2011 19:45:33 -0700 (PDT)
> You then go on to speak about LEON, does LEON implement PSO?
BTW, even if it does, I would be encouraging the person who submits
LEON kernel patches to not run the chip in this mode.
We don't even use PSO for v9 chips, i
From: Geert Bosch
Date: Mon, 27 Jun 2011 23:17:18 -0400
>> \You then go on to speak about LEON, does LEON implement PSO?
> No, I'm not talking about PSO anywhere or SPARCv9 anywhere.
> Just plain old SPARCv8, using the TSO model. This requires a
> load-store instruction to guarantee a full memor
From: Eric Botcazou
Date: Tue, 28 Jun 2011 10:11:03 +0200
> The V8 architecture manual is quite clear about it: TSO allows stores to be
> reordered after subsequent loads (it's the only difference in TSO with Strong
> Consistency) so you need to do something to have a full memory barrier. As
From: Eric Botcazou
Date: Tue, 28 Jun 2011 23:27:43 +0200
> With the pristine compiler, the test passes with -mcpu=v9 but fails otherwise.
> It passes with the patched compiler. However, I suspect that we would still
> have problems with newer UltraSparc CPUs supporting full RMO, because the ne
From: Rainer Orth
Date: Tue, 12 Apr 2011 15:00:53 +0200
> On Solaris 10, as assembles the test just fine, but ld cannot deal with
> gas 2.21 output:
>
> ld: fatal: relocation error: R_SPARC_GOTDATA_HIX22: file gotdata.o: symbol
> : offset 0xff370163 is non-aligned
> ld: fatal: relocation error:
From: Rainer Orth
Date: Wed, 13 Apr 2011 19:16:32 +0200
> David Miller writes:
>
>> From: Rainer Orth
>> Date: Tue, 12 Apr 2011 15:00:53 +0200
>>
>>> On Solaris 10, as assembles the test just fine, but ld cannot deal with
>>> gas 2.21 ou
From: Rainer Orth
Date: Tue, 26 Apr 2011 17:25:56 +0200
> David,
>
>>> Thanks Rainer, if you cons up a patch to add the ".align" directive I'll ACK
>>> that as well.
>>
>> here's the patch that I've been testing over the weekend. It caused no
>> change for HAVE_AS_SPARC_GOTDATA_OP on anything b
From: "Joseph S. Myers"
Date: Thu, 10 Mar 2011 01:01:12 + (UTC)
> In the course of preparing target changes to avoid global state in
> option handlers (and use more .opt facilities to simplify those
> handlers) I found that SPARC has a PROCESSOR_NIAGARA2 enumeration
> value but maps "niagara2
From: Rainer Orth
Date: Mon, 11 Apr 2011 14:57:58 +0200
> The follwing patch uses the easy way out and just tests ld_ver. Tested
> with make configure-gcc on sparc-sun-solaris2.11 with Sun as/ld, GNU
> as/Sun ld, and GNU as/ld without change to gcc/auto-host.h and no linker
> error.
Just out of
301 - 363 of 363 matches
Mail list logo
