similar to: [LLVMdev] Bitwidth of Machine Instructions

On Fri, 8 Jun 2007, Babak Salamat wrote: > I am wondering if there is any way to figure out bitwidth of Machine > Instructions. I see that ValueType information is available for nodes > of DAG, but I couldn't find similar info for Machine Instructions. I > particularly need this information for x86 target. > I appreciate your help and comments in this regard. Do you mean the

On Jun 8, 2007, at 10:05 AM, Chris Lattner wrote: > On Fri, 8 Jun 2007, Babak Salamat wrote: >> I am wondering if there is any way to figure out bitwidth of Machine >> Instructions. I see that ValueType information is available for nodes >> of DAG, but I couldn't find similar info for Machine Instructions. I >> particularly need this information for x86 target.

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

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

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

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

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 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, 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

Hello, I am trying to add an instruction before each function call to add/ subtract the stack pointer by a value specified at the command line. I wonder if I can do that during lowering. For example, in X86TargetLowering::LowerCALL. I appreciate it if you give me some hints how and where I can do that. Thank you, Babak

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

Does llvm have a pass that minimizes the bitwidth of llvm instructions? For instance:   %8 = and i32 %7, 63 63 is 111111 in binary. So the 'and' instruction only requires 6 bits. We could rewrite the above code as:   %8 = trunc i32 %7 to i6   %9 = and i6 %8, 63 Since we only need the lower 6 bits we could also propagate this change backwards to reduce the bitwidth of prior

Hi, LLVMers, has someone implemented bitwidth analysis for LLVM? I was looking for something similar to the bitwise compiler described in "Bidwidth analysis with application to silicon compilation, by Mark Stephenson, Jonathan Babb and Saman Amarasinghe" e.g.: http://portal.acm.org/citation.cfm?id=349299.349317 all the best, Fernando

We have a bitwidth analysis that can be downloaded. It is not in LLVM. There should be a link in the paper: http://www.cs.utah.edu/~regehr/papers/pldi075-cooprider.pdf John Regehr

Hello, In http://llvm.org/viewvc/llvm-project?view=revision&revision=177889 and http://llvm.org/viewvc/llvm-project?view=revision&revision=177890 (along with some follow-up patches) the PowerPC back end was changed to use types instead of register classes in instruction patterns. This matched similar changes that Jakob made for Sparc in r177835. I've recently come across an

After doing a bunch of work for moving pre-legalize extended ValueTypes into a table in SelectionDAG, I may have just found a simpler approach. There are under 32 simple ValueType values, so we only really need 5 bits to represent those. ValueType is already a 32-bit type on most hosts; what if we make use of the remaining 27 bits instead of using an external table? If we can assume that vector

I've actually got an implementation of this as an arbitrary precision integer extension that I've written up an RFC for (but not submitted). Below is my copy/pasted RFC (again, not reviewed, but I DO have an implementation of it that I need to prepare for review). I suspect my implementation will do what you need out of it. Its actually more significant than just adding a normal

Chris Lattner wrote: > However, I don't see any reason to base this off of strings. Instead > of passing down "f32" as a string, why not do something like this > pseudo code: > > class X86ValueType { > RegisterClass RegClass; > ... > } > > def X86_f32 : X86ValueType { > let RegClass = FR32; > ... }; > def X86_i32 :