search for: dc552

...ocating memory in that range. > > I'm sure there must be a way to allocate memory in that range on FreeBSD. > The system loader has to do it, right? I just don't know what makes it > happen. > > -Andy > > -----Original Message----- > From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David > Chisnall > Sent: Friday, May 10, 2013 11:06 AM > To: Kaylor, Andrew > Cc: LLVM Developers Mailing List > Subject: Re: TLS with MCJIT (an experimental patch) > > Without the MSP_32BIT part, I consistently hit this assertion: > > As...

...That is, the memory manager isn't allocating memory in that range. I'm sure there must be a way to allocate memory in that range on FreeBSD. The system loader has to do it, right? I just don't know what makes it happen. -Andy -----Original Message----- From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall Sent: Friday, May 10, 2013 11:06 AM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: TLS with MCJIT (an experimental patch) Without the MSP_32BIT part, I consistently hit this assertion: Assertion failed: ((Type == ELF::R_X86_64_32...

...t. If the patch works when memory is loaded below 2GB then it would be possible to right a sophisticated memory manager that surveys the available memory in that space and selects an appropriate block in some non-deterministic manner. -Andy -----Original Message----- From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall Sent: Wednesday, May 08, 2013 6:53 PM To: Kaylor, Andrew Cc: LLVM Developers Mailing List Subject: Re: TLS with MCJIT (an experimental patch) Hi, Unfortunately, I can't compile this patch. MAP_32BIT is a Linuxism that doesn't work on FreeB...

...en memory is loaded below 2GB then it would be possible to right a sophisticated memory manager that surveys the available memory in that space and selects an appropriate block in some non-deterministic manner. > > -Andy > > -----Original Message----- > From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall > Sent: Wednesday, May 08, 2013 6:53 PM > To: Kaylor, Andrew > Cc: LLVM Developers Mailing List > Subject: Re: TLS with MCJIT (an experimental patch) > > Hi, > > Unfortunately, I can't compile this patch. MAP_32BIT is a...

...support MIPS.  So can I fix this? In my hello.c code I have only stdio.h header file.    =========================================== Phone : 82-42-860-1838 Fax : 82-42-860-6790 Cell Phone: 82-10-7599-1981 =========================================== --- On Mon, 11/12/12, David Chisnall <dc552 at cam.ac.uk> wrote: From: David Chisnall <dc552 at cam.ac.uk> Subject: Re: [LLVMdev] Mips instructions using llvm? To: "janarbek" <canarbekmatay at yahoo.com> Cc: "Eli Friedman" <eli.friedman at gmail.com>, llvmdev at cs.uiuc.edu Date: Monday, November 12,...

...'bar2' have different outcomes. However, I think that the new optimisation is neat and valid and I am not suggesting that it should be changed, but it would be useful if a target could override this if they choose to do so. MartinO -----Original Message----- From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall Sent: Tuesday, October 3, 2017 12:20 PM To: ORiordan, Martin <martin.oriordan at intel.com> Cc: Sanjoy Das <sanjoy at playingwithpointers.com>; llvm-dev <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Change in optimisation wit...

Hi Eli, What do you mean by "kind of vague" ? So does not guarantee to generate correct instructions ? I just tried what you said but getting following error ? Any ideas ? What I did is clang hello.c -S -target mips-unknown-linux Error: In file included from hello.c:1In file included from /usr/include/stdio.h:28/usr/include/features.h:323:10 fatak error 'bits/predefs.h' file not

On 17 Nov 2012, at 00:12, Kaylor, Andrew wrote: > My best guess is that this is trying to set up something that’s actually backed by two pages where whatever is written to the RW page will be copied to the RX page, though if that’s possible it would seem to defeat the purpose of not allowing RWX. The correct way of implementing this is to have one physical page mapped to two locations in

...ings like pre_store and post_store, though? If there was a pre_load and post_load this would largely solve the problem. Of course there are a wealth of addressing modes for the 68k, but they should be able to be dealt with like this I think? -----Original Message----- From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall Sent: 09 July 2015 10:58 To: James Boulton Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] New backend help request. The simple answer is: not very easily. I’d be inclined to treat instructions like these as optimisations and ignore them (aside...

On Nov 28, 2012, at 9:30 AM, David Chisnall <dc552 at cam.ac.uk> wrote: > On 28 Nov 2012, at 17:02, Tanya Lattner wrote: > >>> 14116 - Inliner incorrectly combines cleanup and catch landing pads >> >> I think this one can be moved out as a release blocker. Too much debate and no action on the bug in over a month. &g...

Hi all, I plan to deprecate the experimental microMIPS64R6 backend for the 5.0 release and remove it after the release. Currently there are no CPUs that use that particular sub-ISA which makes it difficult to justify the maintenance and parallel development effort. If there was a CPU design produced that did use microMIPS64R6, the backend could be restored from the archive. Any comments or

Hi all, Sorry to bother you guys with this question coming from a young beginner, but even after some hours of research, I could not find any way to solve my issue... I have a project using LLVM APIs (3.7.0), so I compile it with options suggested by 'llvm-config -cxxflags', including -fno-rtti. Without this latter option, the build fails ("no reference to typeinfo...").

On 28 Nov 2012, at 17:02, Tanya Lattner wrote: >> 14116 - Inliner incorrectly combines cleanup and catch landing pads > > I think this one can be moved out as a release blocker. Too much debate and no action on the bug in over a month. This bug means that we can't compile at anything over -O1, or we get code that does the wrong thing (e.g. terminate instead of catching an

...86 backend has appropriate instructions. But during DAG selection we just lose this information and always generate unordered fcmp. I.e. in case of ordered fcmp the vcomiss should be generated, and in case of unordered - vucomiss. - Elena -----Original Message----- From: Dr D. Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall Sent: Thursday, August 29, 2013 10:50 To: Tim Northover Cc: Demikhovsky, Elena; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Ordered / Unordered FP compare are not handled properly on X86 On 29 Aug 2013, at 08:19, Tim Northover <t.p.northover at...

On 29 Aug 2013, at 08:19, Tim Northover <t.p.northover at gmail.com> wrote: > If so, a compare that used that instruction would have to become more > like an "invoke" with a landingpad for the exception and so on, > wouldn't it? The current fcmp can already distinguish between ordered > and unordered, because ucomiss provides that information. There are currently

I'm trying to figure out how to map more complex CISC instructions now. For example on the 68000, you have things like -- add.w (a0)+,(a1)+ So that equates to: temp1 = load a0 add 2, a0 temp2 = load a1 temp1 = add temp1, temp2 store temp1, a1 add 2, a1 How do I express that in a form for LLVM? I see things like pre_store and post_store, but I cant find anything in the way of documentation

Hi, Unfortunately, I can't compile this patch. MAP_32BIT is a Linuxism that doesn't work on FreeBSD (or OS X, or, as far as I can tell, anywhere except Linux). We can consider adding something similar to FreeBSD (although I'm hesitant to encourage anything that increases the determinism of the memory layout of JITed code, for security reasons), but it doesn't seem ideal.

...-tree target needs them, but I’d be happy to try to extract the relevant parts and put them up for review if this is generally useful. We also have an internal diff, but we are trying to upstream everything that has a common sense. - Elena -----Original Message----- From: David Chisnall [mailto:dc552 at hermes.cam.ac.uk] On Behalf Of David Chisnall Sent: Tuesday, January 16, 2018 12:47 To: Demikhovsky, Elena <elena.demikhovsky at intel.com> Cc: llvm-dev at lists.llvm.org; Sanjay Patel (spatel at rotateright.com) <spatel at rotateright.com>; Chandler Carruth (chandlerc at gmail.com)...

On 4 Jul 2016, at 12:27, Renato Golin via Openmp-dev <openmp-dev at lists.llvm.org> wrote: > > On 4 July 2016 at 00:42, Robinson, Paul <paul.robinson at sony.com> wrote: >> Daniel claimed it was not different, even though he proposed the text. >> I think it is better, as "egregious" (even though it is qualitative) >> helps identify what

Have you tried the git-imerge add-on? https://www.youtube.com/watch?v=FMZ2_-Ny_zc On Tue, Jun 7, 2016 at 5:17 AM, Robinson, Paul via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > > -----Original Message----- > > From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of > David > > A. Greene via llvm-dev > > Sent: Thursday, June 02,