similar to: [LLVMdev] Clarification on alloca semantics

Is there any reason why it is saying "generic address space (address space zero)" and not just "address space zero"? -- Sean Silva -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130712/2444b767/attachment.html>

On Thu, May 23, 2013 at 8:13 AM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > That sounds like a missed multi-threading issue with LLVM. I can't > imagine why the user should be forced to serialize creation of MCContext > objects. I would suggest filing a bug for this. A simple lock probably > wouldn't be too detrimental to performance here, since

In the past, I've just referenced Chris's CGO 2004 paper when referring to LLVM: C. Lattner and V. Adve. LLVM: A compilation framework for lifelong program analysis & transformation. For sub-projects like Clang and DragonEgg, I just cite the URLs: [4] Clang. clang.llvm.org. [5] DragonEgg. dragonegg.llvm.org. I don't know of any canonical references for these. On Sun, Apr 14,

Hi, This is quite a simple question so hopefully it's easy to answer. I was looking at the documentation for the alloca instruction ( http://llvm.org/docs/LangRef.html#alloca-instruction ) and something is unclear to me. The given syntax is... <result> = alloca <type>[, <ty> <NumElements>][, align <alignment>] ; yields {type*}:result And the documentation

On 15/08/13 16:12, Tim Northover wrote: >> I've obviously being playing with C++ too long because my >> instinct immediately told me that dynamically sized arrays on >> the stack are't allowed but apparently that's fine for C99 (g++ >> also seems fine with this is you don't specify -pedantic) > > It's all fun and games until someone decides to

> I've obviously being playing with C++ too long because my > instinct immediately told me that dynamically sized arrays on the > stack are't allowed but apparently that's fine for C99 (g++ also seems > fine with this is you don't specify -pedantic) It's all fun and games until someone decides to evaluate sizeof(arr). ;-) I think a more limited form is coming to

Thanks for the reply. Please see my inline responses. On 15/08/13 12:58, Tim Northover wrote: > Hi Dan, > >> It is not stated how the "<ty>" type is used as we are told the >> type of result is type* and sizeof(<type>)*NumElements is the >> amount of memory so from my perspective it looks like <ty> is >> never used which would seem to

It looks like someone got started on this project: http://www.llvm.org/devmtg/2010-11/Spencer-ObjectFiles.pdf Does anyone know what kind of progress has been made? On Sat, May 14, 2011 at 9:10 AM, Reed Kotler <rkotler at mips.com> wrote: > It's not so easy to create a linker that has all the bells and whistles, > especially on windows. > You have to look at the totality of

It looks like it is kind of stalled: ~/extern/llvm.head/lib/Object $ svn log On Sat, May 14, 2011 at 11:07 AM, Hans Stimer <hans.stimer at gmail.com> wrote: > It looks like someone got started on this project: > > http://www.llvm.org/devmtg/2010-11/Spencer-ObjectFiles.pdf > > Does anyone know what kind of progress has been made? > > > On Sat, May 14, 2011 at 9:10

On Fri, May 13, 2011 at 2:20 PM, Hans Stimer <hans.stimer at gmail.com> wrote: > It appears that when you link bitcode files into a native executable using > llvm-ld, that gcc is used for the final step. > > I would like to create a tool that creates native executables without > requiring gcc/clang. Is that currently supported with llvm? > To create executables, LLVM

It's not so easy to create a linker that has all the bells and whistles, especially on windows. You have to look at the totality of options, linker files, shared objects, etc. It's not a weekend project. If you want to read the elf manual and gnu ld and then write a new one you could do that. Clang can easily be fixed to incorporate it either as a default or as an optional linker. The

Yep, sorry, we ran out of space on the instance's database volume. I'll update this once we're back up. On Thu, Jul 11, 2013 at 9:07 PM, Justin Holewinski < justin.holewinski at gmail.com> wrote: > Is Phabricator down again? I'm starting to see the following: > > [Rendering Exception] Multiple exceptions during processing and rendering. > -

On Tue, Dec 4, 2012 at 4:27 AM, Tobias Grosser <tobias at grosser.es> wrote: > Why don't you give it a try. This will also help us to understand where > the biggest > problems are and if the necessary changes make supporting python 2.4 > hard. I'll see what I can do. Since on that machine I only have python3 and python2.7, I can't easily verify that my changes still

On Fri, Jun 22, 2012 at 3:16 PM, amruth.rd <amruth.rd at knights.ucf.edu>wrote: > Thanks Justin. It was really helpful. > > Can i use "alloca" instruction to allocate memory at a particular address > in the stack? Is it possible to do that? As far as I know, alloca does not > take any address as an operand. > The only control alloca gives you over the address is

The code itself makes sense, but I want to know if this breaks any guarantee made about preserving a Value* in the MachineMemOperand. It sounds like we're having the same issue. We were using the Value* stored in the MachineMemOperand to get address space information during assembly printing. The alternative is carrying around a lot of extra (redundant) information in the SDAG. If it is

On Sun, Jan 13, 2013 at 2:10 PM, Matthieu Monrocq <matthieu.monrocq at gmail.com> wrote: > gcc 4.5, MSVC 10, clang 3.1 > - decltype v1.0 [1] + late specified return type > - lambda v1.0 [2] > - local types as template arguments > - r-value 2.0 [3] > - static_assert > - built-in type traits This isn't very encouraging. Anecdotally from what I've seen in LLD

I want to get some clarification on the exact semantics of the MachineMemOperand attached to memory-touching instructions. From what I understand, a MemSDNode has an associated MachineMemOperand and a MachineInstr can have zero or more attached MachineMemOperands. But what is the guarantee/constraint placed on optimization/codegen passes for maintaining the contents of a MachineMemOperand? In

Hello, I created a new block for execution to continue, but I got the case in which a statement defined in a block is used in another, not dominate all uses. For example: entry: %n_addr = alloca i32, align 4 %retval = alloca i32 %"alloca point" = bitcast i32 0 to i32 store i32 %n, i32* %n_addr %0 = call i32 (i8*, ...)* @printf(i8* noalias getelementptr inbounds ([20 x i8]*

Subject: Singaporean Mr. Teo En Ming's Refugee Seeking Attempts, In Search of a Substantially Better Life In reverse chronological order: [1] Petition to the Government of Taiwan for Refugee Status, 5th August 2019 Monday Photo #1: At the building of the National Immigration Agency, Ministry of the Interior, Taipei, Taiwan, 5th August 2019 Photo #2: Queue ticket no. 515 at the National

Sean, I can create html, pdf and epub, then put them on <https://github.com/Jonathan2251/lbd/tree/gh-pages>. The uvbook example as below can click the pdf link and pop up a download window while I cannot. The uvbook link is put on http://username.github.com/... while the "make gh-pages" put them on https://github.com/username/...  How can I have the download link like uvbook