similar to: [LLVMdev] Extend llvm to fix global addresses

On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote: > It would be nice to add support for placing globals at fixed addresses in memory. I don't know. From my experience, the usefulness is very, very limited. As in: drivers are about the only thing that can make use of it. > For example, low level driver code tends to contain things like this > > *(int*)0x00001000

(resent due to mailing list breakage) On Dec 6, 2011, at 6:55 AM, Joerg Sonnenberger wrote: > On Mon, Dec 05, 2011 at 07:18:36PM -0800, Peter Cooper wrote: >> It would be nice to add support for placing globals at fixed addresses in memory. > > I don't know. From my experience, the usefulness is very, very limited. > As in: drivers are about the only thing that can make

The best case i can think of is embedded developers needing to layout functions or globals in memory. Currently they would have to resort to a linker script or assembly hacks for this. But anything which avoids the horrible int* cast has to be a good thing. For one thing it would cause alias analysis a lot of pain. On Dec 6, 2011, at 3:23 PM, David Blaikie wrote: >> We've spoken

On Dec 6, 2011, at 3:29 PM, Peter Cooper wrote: > The best case i can think of is embedded developers needing to layout functions or globals in memory. > Currently they would have to resort to a linker script or assembly hacks for this. This proposal also requires extending object file formats and linkers, and this impacts a lot of people, so it would want a pretty compelling

> We've spoken to several people who do write drivers and > other code like the above, and they seem pretty enthusiastic about the > idea.  If you have input about how best to design this, at any of the levels > Peter spelled out, that would be interesting. I'm curious what the particular benefits/differences would be between this language feature & the existing solution

> On May 30, 2017, at 3:52 PM, Joerg Sonnenberger <joerg at bec.de> wrote: > > On Tue, May 30, 2017 at 03:49:38PM -0700, Pete Cooper via llvm-dev wrote: >> Aw, but i had a list of issues, such as: >> - tablegen doesn’t generate .d files > > Actually, it does if asked to. Oh, thanks. Thats good to know. I don’t know if ninja uses the .d as the source of real

On Sat, Oct 15, 2016 at 04:01:36PM -0700, Mehdi Amini via llvm-dev wrote: > > > On Oct 15, 2016, at 3:56 PM, Wolfgang McSneed via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > > Hi, > > > > I am hoping that someone can help me figure out how to prevent the insertion of "memcpy" from the assembly source. > > > > My target is an

+1 from me. But which version of 4.8.x? 4.8.0 was released in March 2013 while 4.8.5 is June 2015 (see https://gcc.gnu.org/releases.html <https://gcc.gnu.org/releases.html>) Thats an awfully long time between those dates, so i can’t imagine everyone being on 4.8.5, but shouldn’t we aim for the highest possible one if we’re bumping versions anyway? Looking at Ubuntu 14.04 LTS

On Mon, Oct 03, 2016 at 02:43:03PM +0200, Michael Kruse via llvm-dev wrote: > 2016-10-03 13:55 GMT+02:00 Martin J. O'Riordan via llvm-dev > <llvm-dev at lists.llvm.org>: > > I am trying to implement some new alignment based optimisations in our > > target backend, and I am wondering if there a way a target can specify that > > ‘malloc’, ‘realloc’ and ‘calloc’

Hello, while debugging assertions when building libm for 32bit Sparc, I hit the following IR: complex_mul_libcall: call void @__muldc3({ double, double }* sret %tmp, double %conv, double 0.000000e+00, double %a.real, double %a.imag) #2 ... declare void @__muldc3({ double, double }*, double, double, double, double) The same IR is essentially generated for i386 too, so it is not Sparc

Bringing this up on llvm-dev for more general attention. The problem here is two fold: (1) Reuse of enumeration values is just a major no-go. (2) I'm not sure why the existing vector types had to be killed completely. But something clearly has to be done here. This majorly affects e.g. Mesa. Joerg ----- Forwarded message from Joerg Sonnenberger via llvm-commits <llvm-commits at

On 16 Aug 2018, at 00:51, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Tue, Aug 07, 2018 at 09:49:16PM +0200, Dimitry Andric via llvm-dev wrote: >> This is a regression caused by https://reviews.llvm.org/rL323281: >> >> ------------------------------------------------------------------------ >> r323281 | wmi | 2018-01-23 23:27:57 +0000

On Sat, Oct 1, 2016 at 11:46 PM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Sun, Oct 02, 2016 at 05:33:40AM +0000, Zachary Turner via llvm-dev > wrote: > > While GCC doesn't claim to "fully" support C++14 until 5.2 (which is only > > about 1 year old), you can get all of the above features with GCC 4.9 > > I do care quite a

On Mon, Jun 18, 2012 at 6:30 PM, Joerg Sonnenberger <joerg at britannica.bec.de > wrote: > On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote: > > On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger < > joerg at britannica.bec.de > > > wrote: > > > > > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany wrote: > > > >

Regarding the numerical value of the LLVMTypeKind enum, my understanding is that LLVM-C does not promise to maintain ABI compatability between versions. If I am mistaken, I can fix this issue. From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of James Y Knight via llvm-dev Sent: Wednesday, May 13, 2020 7:33 AM To: Joerg Sonnenberger <joerg at bec.de>; llvm-dev <llvm-dev

> On May 2, 2016, at 2:48 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, May 02, 2016 at 02:39:12PM -0700, Quentin Colombet wrote: >> Hi Joerg, >> >>> On May 2, 2016, at 2:33 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> On Mon, May 02, 2016 at 01:35:27PM -0700,

On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger <joerg at britannica.bec.de > wrote: > On Mon, Jun 18, 2012 at 05:19:11PM +0400, Kostya Serebryany wrote: > > On Mon, Jun 18, 2012 at 5:07 PM, Joerg Sonnenberger < > joerg at britannica.bec.de > > > wrote: > > > > > On Mon, Jun 18, 2012 at 02:39:34PM +0400, Kostya Serebryany wrote: > > > >

On Mon, Dec 08, 2014 at 11:46:45AM -0800, David Majnemer wrote: > I'm pretty sure this is fixed in r223684. This particular use of > zero-sized arrays should defeat any chance of compile-time address equality. I object that change. It's a horrible special case hack for either a fundamental issue in the IR or plain UB on the source level. As such, it should be reverted. Joerg

On Mon, Jun 18, 2012 at 06:44:57PM +0400, Kostya Serebryany wrote: > On Mon, Jun 18, 2012 at 6:30 PM, Joerg Sonnenberger <joerg at britannica.bec.de > > wrote: > > > On Mon, Jun 18, 2012 at 05:52:49PM +0400, Kostya Serebryany wrote: > > > On Mon, Jun 18, 2012 at 5:43 PM, Joerg Sonnenberger < > > joerg at britannica.bec.de > > > > wrote: > >

On 4/15/16, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > On Fri, Apr 15, 2016 at 02:31:59PM +0200, ardi via llvm-dev wrote: >> On Fri, Apr 15, 2016 at 1:02 PM, Joerg Sonnenberger via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> > On Fri, Apr 15, 2016 at 10:45:03AM +0200, ardi via llvm-dev wrote: >> >> What I found is