similar to: [RFC] Remove Darwin support from POWER Backends

Hi, I am wondering why we dont support PPC32 LE? Here is the output of llvm-mc --version, in which only PPC32, PPC64 & PPC64LE are supported. $ llvm-mc --version LLVM (http://llvm.org/): LLVM version 3.6.2 Optimized build with assertions. Built Aug 2 2015 (11:39:46). Default target: x86_64-apple-darwin15.4.0 Host CPU: core-avx2 Registered Targets: aarch64 - AArch64

Hi everyone, I don't believe that anyone is currently using (a recent) LLVM on PowerPC/Darwin. As far as I know, Apple stopped supporting PowerPC hardware years ago. There is a significant amount of code in the PowerPC backend dedicated to Darwin support and removing it would make maintaining the rest of the backend easier. If anyone expects upcoming LLVM releases to continue to support

----- Original Message ----- > From: "Eric Christopher" <echristo at gmail.com> > To: "Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal > Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> > Sent: Wednesday, February 10, 2016 6:59:50 PM > Subject: Re: [llvm-dev] [PPC] Linker fails on

I'll come up with a address-space-based proof of concept. On Wed, Feb 10, 2016, 17:05 Eric Christopher <echristo at gmail.com> wrote: > On Wed, Feb 10, 2016 at 5:04 PM Hal Finkel <hfinkel at anl.gov> wrote: > >> >> ------------------------------ >> >> *From: *"Eric Christopher" <echristo at gmail.com> >> *To: *"Tim

I found a bit weird to use address space for this, since the offset of getting stack_guard in TCB is, unfortunately, negative: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610 In my understanding an address space is referring to a segment register (-on powerpc 32bit; or SLB entry on powerpc 64bit?) with a non-negative offset value, so that it's actually accessing

<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial, Helvetica, sans-serif;font-size:9pt" ><div dir="ltr" >Hi all,</div> <div dir="ltr" >I'm very excited to be able to share this with everyone. </div> <div dir="ltr" > </div> <div dir="ltr" >IBM announced this

Hi, Sorry for bringing back such an old thread. I am interested in the latest status of the shrink wrapping pass in LLVM. I have found some active work back in 2017 from Francis Visoiu Mistrih and Kit Barton from the following links. However, it seems that all the work suddenly stops and the improvement for the existing shrink wrapping did not make it into the trunk. Is this work abandoned?

When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" because at least for powerpc64le, glibc doesn't provide this symbol. Instead, they put the stack guard into TCB. x86 fixed this issue by injecting a special address space (which is later translated to TCB register access) and hard code the offset of stack_guard, but I don't see a easy way to

Hi, I am following the instructions on Writing an LLVM Pass on Darwin(8.7.0) powerpc. The loadable library is built. But "opt -load " gives error saying "Symbol not found". I am using LLVM 1.8. Could someone tell me how to fix it? I have tried the same procedure on Pentium4 Redhat9. Everything is ok there. So I think there must be some specific problem on Darwin that I should

Hi all, TL;DR: Should the loop guard branch be part of the canonical loop structure? Background: ----------- While working on the next set of improvements to loop fusion, we discovered that loop rotation will put a guard around a loop if it cannot prove the loop will execute at least once, as seen in the following (simplified) example: entry: br i1 %cmp1, label %for.body.lr.ph, label

Hi Francis, Thanks for getting back to me. Could you please provide more details about the problems you encounter with those tools and what improvements required to improve compact unwinding format? Most of my experience is in the mid end, but it is still surprising to me that an improved shrink wrap will break that many tools, considering the fact that gcc has a good shrink wrapping pass and

Hi James, I agree, we should keep a mode that prints register names (instead of just the numbers). I lean toward having a verbose mode that is compatible with the GNU assembler, which means %r1 instead of just r1. gas will also accept that syntax, so it seems more useful than the Darwin syntax on current systems. What do you think? -Hal ----- Original Message ----- > From: "James Y

Thank you, Reid. I have applied tha patch to ltdl.c ltdl.h. The problem still exists. I looked up the symbol on libLLVMCore.a, and found three U-entries and one T-entry. However, the Darwin linker is not able to find the T-entry. Any idea? pollux:~/test jingyu$ opt -load /Users/jingyu/tools/build-ppc/Release/lib/LLVMHello.so -help Error opening

I don't remember the details of the particular case where we encountered this, but I think the loop started with the condition check and ended with an unconditional branch back to the beginning. -- Krzysztof Parzyszek  kparzysz at quicinc.com   LLVM compiler development -----Original Message----- From: Philip Reames <listmail at philipreames.com> Sent: Thursday, May 30, 2019 3:00 PM

So I couldn't get exceptions to work on PPC darwin. After much digging and confusion, there seem to be two separate issues. The gcc testsuite is running the version of the unwinding code that was built with the local (llvm-)gcc, which doesn't work because nobody has implemented builtin_return_address for that target. So that's one problem. More seriously, the version of the

Hi all, We've seen several examples recently of performance opportunities on POWER if we can improve the location of save/restore code for callee-saved registers. Both Nemanja and myself have discussed this with several people, and it seems that there are two possibilities for improving this: 1. Extend shrink wrapping to make the analysis of callee-saved registers more precise. 2.

On Sun, 2006-08-27 at 21:57 -0500, Jing Yu wrote: > Hi, > Hi Jing, > I am following the instructions on Writing an LLVM Pass on > Darwin(8.7.0) powerpc. The loadable library is built. But "opt -load > " gives error saying "Symbol not found". I am using LLVM 1.8. Could > someone tell me how to fix it? I have tried the same procedure on > Pentium4 Redhat9.

Hi, a while back I wrote that the llvm makefiles didn't create the correct kind of file for use on darwin with -load. Since then, both the shared library and makefile system have been overhauled significantly. So I checked again - as updated from CVS, the current makefiles don't build the right object type on darwin. If you follow the advice of 'Writing an LLVM Pass" tutorial,

Hello, Bill. > It's not exactly tweaking magic knobs. It's doing something that's > already done -- putting the information in the TAI object, and > allowing the specific back-end to set the appropriate strings. It seems to me, that simple strings / bools there are not enough :) "$non_lazy_ptr" emission is already in asm printers (in 2 places!). The

Adding +Eric Liu <ioeric at google.com> who helps with Phabricator.... On Sun, Jun 25, 2017 at 3:15 PM Davide Italiano via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Jun 25, 2017 at 12:32 PM, Anton Korobeynikov > <anton at korobeynikov.info> wrote: > > Thanks, fixed. > > > > Also, FWIW, phabricator commit mails are broken. Example: > >