similar to: [LLVMdev] (no subject)

Hi, During isel lowering, the backend insertes CALLSEQ_START / CALLSEQ_END target independent nodes to the DAG. These are then selected to X86 specific instructions ADJCALLSTACKDOWN / ADJCALLSTACKUP. At these point, they have a constant arguments which corresponds to the fixed frame size for argument passing. But the size of the stack frame isn't finalized until frame layout has

Hi LLVM-Devs, I have managed to complete updating our sources from LLVM v4.0 to v5.0, but I am getting selection errors for 'callseq_end'. I am aware that the 'ADJCALLSTACKUP' and 'ADJCALLSTACKDOWN' patterns have changed, and have added an additional argument to the TD descriptions for these. There are interactions with 'ISD::CALL' and 'ISD::RET_FLAG',

Hi, I am trying to compile glibc on Linux using llvm. I need to do this for a research project. The problem is that llvmc doesn't work, and I guess I have to set CC=llvmc to get the glic compiled. For some reason llvmc complains that it cannot find %llvmcc1%. I have this problem both on my Mac and my Linux system. Other tools that I have tested including llvm-gcc work without any

Reid, Thank you for your quick reply. Yes, I have built and installed llvm-gcc and "llvm-gcc --print-prog- name=cc1" return the correct path for cc1, so I assume its path is set correctly in the config files, but I haven't installed config files separately. Do I need to do that? Is there any documentation about it? Thank you again, Babak On May 8, 2007, at 7:33 PM, Reid

Thank you Chris. Actually, I have changed the stack organization in the "llc" source codes for x86 target. Thus, I need libraries compiled with the new stack organization. If I use llvm-gcc (and apparently also llvmc), llc will not be invoked. I was hoping that llvmc would call llvm-gcc to compile to bc file and then call llc to compile to native assembly, but apparently this

I am convinced to use llvm-gcc. As I mentioned in my previous email, I have changed native code generation in llc to generate code with a different stack organization. In order to have working binaries, the libraries must be compiled with the new tool and have the same stack organization. Now that I cannot use llc, it seems that I have to modify llvm-gcc to have it generate code with the

Hi Martin, Pseudo CALLSEQ_START was changed in r302527, commit message contains details on the changes. However CALLSEQ_END was not modified. If your made changes to ADJCALLSTACKUP to add additional argument, that may result in error. Thanks, --Serge 2017-09-15 19:09 GMT+07:00 Martin J. O'Riordan via llvm-dev < llvm-dev at lists.llvm.org>: > Hi LLVM-Devs, > > I have managed

On Tue, 8 May 2007, Babak Salamat wrote: > Yes, I have built and installed llvm-gcc and "llvm-gcc --print-prog- > name=cc1" return the correct path for cc1, so I assume its path is > set correctly in the config files, but I haven't installed config > files separately. Do I need to do that? Is there any documentation > about it? I'd strongly suggest just building

Babak, As its manual page (http://llvm.org/docs/CommandGuide/html/llvmc.html) states, llvmc is an experimental tool: llvmc is considered an experimental LLVM tool because it has these deficiencies: Poor configuration support The support for configuring new languages, etc. is weak. There are many command line configurations that cannot be achieved with the current

Hi Serge, Thanks for your help. I have looked at the change log, and so far as I can tell, my implementation is pretty much identical to all of the in-tree targets, but I’m missing something and can’t see what it is. I have simplified my TD description to just: def MyCallseqStart : SDNode<"ISD::CALLSEQ_START", SDCallSeqStart<[SDTCisVT<0, i32>,

Babak, I strongly suggest you drop trying to use llvmc. Instead, probably just compiling your library with llvm-gcc should be sufficient. The llvm-gcc tool has much of llc's functionality built in to it so you're going to get the same output. If that doesn't work for you, then please describe what you're trying to do in more detail and we'll tell you how it can be done.

On Wed, 2007-05-09 at 13:38 -0700, Babak Salamat wrote: > I am convinced to use llvm-gcc. As I mentioned in my previous email, > I have changed native code generation in llc to generate code with a > different stack organization. In order to have working binaries, the > libraries must be compiled with the new tool and have the same stack > organization. Now that I cannot use

On Tuesday 08 December 2009 14:43, David Greene wrote: > On Tuesday 08 December 2009 14:00, David Greene wrote: > > I just filed PR 5723. This is a rather serious bug for us, > > causing all sorts of problems in creating dynamically-linked > > C++ programs due to the C++ runtime containing lots of leaf-like > > routines that use thread-local storage. > > > >

Hello, David > For X86 CALLSEQ_START gets selected to ADJCALLSTACKDOWN or > ADJCALLSTACKDOWN64 in this case.  So is CALLSEQ_START expected > to appear only once (at the top of the function)?  The comments > are rather confusing.  It seems like CALLSEQ_START is supposed > to appear before every call, but surely there's only one stack > adjustment in the final code. Right.

Hi, Is there a kind of scope mechanism in the instruction lowering pattern language in order to control where instructions are inserted or how they are later reordered during the SelectionDiag linearization? I know the glue chain that stick instructions together. But such mechanism in not provided in instruction lowering pattern. I'm facing many situations where some patterns are lowered into

Reid and Bill, Thank you very much for your helpful comments. Your comments helped me find out what part of my work was wrong that my changes were not effective in llvm-gcc. Thank you again, Babak On May 9, 2007, at 1:57 PM, Reid Spencer wrote: > On Wed, 2007-05-09 at 13:38 -0700, Babak Salamat wrote: >> I am convinced to use llvm-gcc. As I mentioned in my previous email, >> I

The DAG dumping will try to print some of the nodes "inline" (i.e. where they are used) to make the output more readable, so the dump of the DAG may not strictly reflect the node ordering. -Krzysztof On 5/4/2018 8:18 AM, Dominique Torette via llvm-dev wrote: > Here is a last example to illustrate my concern. > > The problem is about the lowering of node t13. > >

Here is a last example to illustrate my concern. The problem is about the lowering of node t13. Initial selection DAG: BB#0 '_start:entry' SelectionDAG has 44 nodes: t11: i16 = Constant<0> t0: ch = EntryToken t3: ch = llvm.clp.set.rspa t0, TargetConstant:i16<392>, Constant:i32<64> t5: ch = llvm.clp.set.rspb t3,

Sure, I've attached it to the bug report. Direct link is here: https://llvm.org/bugs/attachment.cgi?id=16840 - Elliot "llvm-dev" <llvm-dev-bounces at lists.llvm.org> wrote on 2016/07/29 03:46:41 PM: > From: Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> > To: llvm-dev at lists.llvm.org > Date: 2016/07/29 03:46 PM > Subject: Re: [llvm-dev]

Krzysztof, Thanks for your interest to my questions. In order to clarify the context, here is the C source file of my test case. The 3 builtins initialize some stack pointers. They have to be executed before any other instruction. extern float fdivfaddfmul_a(float a, float b, float c, float d); volatile static float x1,x2,x3,x4; void _start(void) { float res;