search for: desugarize

Hey, I am Swapnil Raj I am student in Trinity College Dublin and I am interested in working on LLVM. I am really interested in two projects listed, the first one is the extending the clang AST with template information and the second is finding smart null pointer dereferences. I am passionate about compilers and interpreters, I have written a few small language based on lambda calculus. I am

David provided one good answer. I'll give another. The current design pushes complexity into the language frontend for - as far as I know - no good reason. I can say from recent experience that the corner cases around atomics are both surprising and result in odd looking hacks in the frontend. To say this differently, why should marking loads and stores atomic required me to rewrite

Hi, Sorry for the hiatus, busy time at my university. :) After a false start and some (hopefully cogent) thought, I am now of the opinion that it will be better to have llvm natively support a somewhat different notion of parallel computation and have the frontend lower OpenMP directives (and possibly other such things) into the same. In short, I propose a intrinsic based approach which hinges

Looking through the documentation, I discovered that atomic loads and stores are only supported for integer types. Can anyone provide some background on this? Why is this true? Currently, given code: std::atomic<float> aFloat; void foo() { float f = atomic_load(&aFloat); .. } Clang generates code like:|| %"struct.std::atomic.2" = type { float } @aFloat = global

On Tue, 14 Aug 2012 10:22:35 +0300 Pekka Jääskeläinen <pekka.jaaskelainen at tut.fi> wrote: > On 08/13/2012 10:54 PM, Hal Finkel wrote: > > I had thought about uses for shared-memory OpenCL implementations, > > but I don't know enough about the use cases to make a specific > > proposal. Is your metadata documented anywhere? > > It is now a quick "brute

How are you representing things like various scheduling mechanisms without metadata - extra parameters to intrinsics ? - dibyendu ----- Original Message ----- From: Sanjoy Das [mailto:sanjoy at playingwithpointers.com] Sent: Wednesday, September 26, 2012 08:36 AM To: Hal Finkel <hfinkel at anl.gov> Cc: llvmdev at cs.uiuc.edu <llvmdev at cs.uiuc.edu>; cfe-dev at cs.uiuc.edu <cfe-dev

On 10/24/13 2:50 PM, Rafael Espíndola wrote: > On 24 October 2013 17:32, Sanjoy Das <sanjoy at azulsystems.com> wrote: >> Hello llvm-dev! >> >> My colleages and I are currently evaluating llvm's suitability as a >> JIT compiler interfacing with a precise, relocating garbage collector. >> While we couldn't find code or writeups that deal with the

Sean, Thanks for doing this research and writing up that summary! The SECTION and MEMORY seem doable in lld as part of the ELF Writer. The one tricky part will be if the linker script defines symbols (e.g. __text_size), because those symbol names might be referenced by some object file atom. Thus they need an atom representation for lld's Resolver to see. So, the ELF Writer will need

...n `addrspace(0)`) is then passed to a function. The test asserts that this memcpy should be removed and the global should just be passed directly to the function, but doesn’t this lose the property that the load should be performed through `addrspace(1)`, as per your comment above? > > Let’s desugarize memcpy to a sequence of load-store as my previous comment implied (simplified for a single i8, otherwise we need a loop or a load of T, but the reasoning seems the same to me): > > > define void @test3_addrspacecast() { > %A = alloca %T > %a = bitcast %T* %A to i8* >...

On Wed, Jan 2, 2013 at 2:53 PM, Nick Kledzik <kledzik at apple.com> wrote: > The SECTION and MEMORY seem doable in lld as part of the ELF > Writer. MEMORY and most aspects of SECTIONS are effectively syntax sugar and the rest of LLD doesn't need to even be aware of it; the ldscript language processor will desugar it. The same is true of many other linker script constructs that I

On 24 October 2013 17:32, Sanjoy Das <sanjoy at azulsystems.com> wrote: > Hello llvm-dev! > > My colleages and I are currently evaluating llvm's suitability as a > JIT compiler interfacing with a precise, relocating garbage collector. > While we couldn't find code or writeups that deal with the issues > specific to this design goal, it is entirely possible that we

What is the best level to use for backend development? We do not need to generate machine code, but rather an intermediate representation that will give us the control flow graph. Is this the llvm IR? If so, how do I read into memory a file that was generated by clang++ -emit-llvm <source file>. Thanks, Sitvanit Sitvanit Ruah Formal Verification Group IBM Haifa Research Laboratory Tel:

> Hi all, > After reading the documentation on clang I still have the following > question: > How do I read the bitcode generated by clang from a C++ file? I need to > have all the AST information in memory. AST has nothing to do with LLVM bitcode. -- Regards, Konstantin

Hi Mehdi, Thanks for the reply - I’ve finally got round to trying to fix this based on your suggestion. I’ve got something that mostly works, but I just wanted to double-check something about the regression tests before I post a patch. > The memcpy is supposed to be equivalent to a sequence of load and store. Here we are just failing to keep the property that the load is performed through

Hello llvm-dev! My colleages and I are currently evaluating llvm's suitability as a JIT compiler interfacing with a precise, relocating garbage collector. While we couldn't find code or writeups that deal with the issues specific to this design goal, it is entirely possible that we may have missed something; we would appreciate references to relevant code or writeups that people on this

On 04/29/2014 12:39 PM, Filip Pizlo wrote: > On April 29, 2014 at 11:27:06 AM, Philip Reames > (listmail at philipreames.com <mailto:listmail at philipreames.com>) wrote: >> On 04/29/2014 10:44 AM, Filip Pizlo wrote: >>> LD;DR: Your desire to use trapping on x86 only further convinces me >>> that Michael's proposed intrinsics are the best way to go.

Hi all, I have been investigating linker scripts and the functionality needed to support them in lld. I have attached my findings about the usage of ldscripts. My findings have been collected from: - Reading all the GNU ld manual sections about linker scripts. - Looking at the GNU ld and gold source code. - Digging through a couple embedded programming tutorials. - Reading through all of the

On May 2, 2014 at 11:53:25 AM, Eric Christopher (echristo at gmail.com) wrote: On Wed, Apr 30, 2014 at 10:34 PM, Philip Reames  <listmail at philipreames.com> wrote:  > Andy - If you're not already following this closely, please start. We've  > gotten into fairly fundamental questions of what a patchpoint does.  >  > Filip,  >  > I think you've hit the nail on

Andy - If you're not already following this closely, please start. We've gotten into fairly fundamental questions of what a patchpoint does. Filip, I think you've hit the nail on the head. What I'm thinking of as being patchpoints are not what you think they are. Part of that is that I've got a local change which adds a very similar construction (called

> > > > Also as a side note, I think in the original MachineOutliner RFC thread > there was some confusion as to whether it was possible to solve the code > folding outlining problem exactly as a graph problem on SSA using standard > value numbering algorithms in polynomial time. > > I can elaborate further, but > 1. it is easy to see that you can map an arbitrary