llvm dev - Oct 2011 - [LLVMdev] is anyone using the sparc backend?

I'm removing old targets that no longer appear actively maintained,
to reduce the burden for target-independent codegen maintenance.

Does anyone object to the removal of the Sparc backend?

Dan

On 10/24/2011 05:45 PM, Dan Gohman wrote:
> I'm removing old targets that no longer appear actively maintained,
> to reduce the burden for target-independent codegen maintenance.
>
> Does anyone object to the removal of the Sparc backend?
>
> Dan
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
People have been working on the Sparc backend recently.

Sometimes these older backends are also good examples of how to code 
something in a new port.

I based the Mips delay slot optimization on that in the Sparc port.

I don't know about the alpha. That machine is fairly dead as far as I know.

Sparc is not dead. Don't delete that.

Reed

> I'm removing old targets that no longer appear actively maintained,
> to reduce the burden for target-independent codegen maintenance.
  I don't know what you exactly mean. Could you give an example?
 
> Does anyone object to the removal of the Sparc backend?
  Writing an LLVM Compiler Backend
  http://llvm.org/docs/WritingAnLLVMBackend.html

  It use SPARC as an example. If SPARC is removed from LLVM, then
the tutorial must be rewritten.

Regards,
chenwj
  
-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

> I'm removing old targets that no longer appear actively maintained,
> to reduce the burden for target-independent codegen maintenance.
But these targets often provide very valuable "live" documentation! 
Especially since the LLVM documentation does not provide a complete 
overview of features at all. If you remove them from the master, they 
should be available for reference somewhere else. I particularly object 
to the removal of sparc, which uses a lot of features and is a very 
important backend reference.

Regards,
Johannes

Dan Gohman wrote:
> I'm removing old targets that no longer appear actively maintained,
> to reduce the burden for target-independent codegen maintenance.
>
> Does anyone object to the removal of the Sparc backend?
>
I have an interest in the SPARC backend (and contributed a patch to improve it 
a few months ago, although I don't think the patch ever got applied). Other 
projects have got in the way, but I still intend to come back to this.

Martin

On 10/25/2011 03:45 AM, Dan Gohman wrote:
> I'm removing old targets that no longer appear actively maintained,
> to reduce the burden for target-independent codegen maintenance.
> 
> Does anyone object to the removal of the Sparc backend?
I was hoping that someone would eventually (re)add JIT support to the Sparc
backend,
and then I would definetely use it in ClamAV.

If the Sparc backend gets removed I don't think anyone will ever bother to
do that, and then LLVM will
only have 2 backends useful to me (with a working JIT): X86 (32/64), and PowerPC
(32/64).
According to my estimates Sparc is more widely used for ClamAV than PowerPC, so
having LLVM support it would be nice.

Best regards,
---Edwin

> If the Sparc backend gets removed I don't think anyone will ever bother
to do that, and then LLVM will
> only have 2 backends useful to me (with a working JIT): X86 (32/64), and
PowerPC (32/64).
  LLVM has a working PowerPC JIT?

-- 
Wei-Ren Chen (陳韋任)
Computer Systems Lab, Institute of Information Science,
Academia Sinica, Taiwan (R.O.C.)
Tel:886-2-2788-3799 #1667

Dan Gohman <gohman <at> apple.com> writes:
> 
> I'm removing old targets that no longer appear actively maintained,
> to reduce the burden for target-independent codegen maintenance.
> 
> Does anyone object to the removal of the Sparc backend?
Removing the SPARC backend would be a pity.
We use it in both teaching and research on embedded systems, targeting
the LEON3 processor from Aeroflex Gaisler [1].

In addition to the other objections raised in this thread, there are ongoing
efforts to build the RTEMS operating system with clang [2]. Quoting [2]:
  
> clang does not support most of the architectures
> supported by RTEMS.  The intersection is x86,
> mips, powerpc, sparc, sparcv9, arm, thumb, and blackfin.
> In some cases, it does not cover the architectural
> variants we care most about.  For example, the
> space community uses hardened SPARC V7 CPUs a lot
> with RTEMS and only V8 is supported by clang right now.
Kind Regards,
Benedikt Huber

[1] http://www.gaisler.com/cms/index.php?option=com_content
&task=section&id=4&Itemid=33 
[2] http://comments.gmane.org/gmane.comp.compilers.clang.devel/15630

On Oct 24, 2011, at 7:54 PM, 陳韋任 wrote:
>> I'm removing old targets that no longer appear actively maintained,
>> to reduce the burden for target-independent codegen maintenance.
> 
>  I don't know what you exactly mean. Could you give an example?
I am making some scheduler changes.  It appears that some of my
changes uncovered a long-standing bug in the Alpha backend. I'm
now debugging the Alpha backend.  This takes effort.

Dan