similar to: [LLVMdev] [fwd] Re: LLVM Compiler Infrastructure

Yeah. We need to have more extra fields in the instruction. Fo example, during high-level synthesis, we must schedule an instruction to a certain control step (or cycle), and bind it to be execute on a certain functional unit, etc. Besides the in-memory exchange of the information, we also want on-disk exchange. That introduces the write-out/parse-in problem. Thanks ----- Original Message -----

I'm CC'ing the llvm-dev list because other people are more knowledgeable about the bytecode format/encoding than I am. Please follow-up the replies to the list. On Wed, Oct 20, 2004 at 11:27:53AM -0700, Yiping Fan wrote: > We also want to extend the llvm instructions/intrinsic > functions/types/passes to support our high-level synthesis for > hardware. First of all, we want to

Chris, thank you for your reply. Our problem is that we don't assume an integer must have 32 bits. In our code generation, we can define an integer to be less than 32 bits. For example, 24 bits. In this case, by executing this LLVM code (my first example) on a 24-bit machine, let x = 0xFFFFFF, then we will get %tmp.2 = 0x003FFF, and %tmp.3 = 0x3FFF, which is positive. That is not correct

> Now we got a small but annoying problem. When we get the following C > code to llvm-gcc, > > short test(int x) { > return (short) (x >> 10); > } > > It will generate the following LLVM code: > short %test(int %x) { > %x = cast int %x to uint ; <uint> [#uses=1] > %tmp.2 = shr uint %x, ubyte 10 ;

int %nlz10(uint %param.x) { %.t3 = shr uint %param.x, ubyte 1 ; <uint> [#uses=1] %.t4 = or uint %.t3, %param.x ; <uint> [#uses=2] %.t7 = shr uint %.t4, ubyte 2 ; <uint> [#uses=1] %.t8 = or uint %.t7, %.t4 ; <uint> [#uses=2] %.t11 = shr uint %.t8, ubyte 4 ; <uint> [#uses=1]

On Thu, 11 Jan 2007, Schimmel, Mark wrote: > file://docs/LangRef.html#globalvars > > The section describing the definition of global vars discusses that you > can specify an alignment and can also specify a section. Could someone > provide an example that works in gccas in release 1.9 for both defining > which section the var is assigned to and defining the variables >

file://docs/LangRef.html#globalvars The section describing the definition of global vars discusses that you can specify an alignment and can also specify a section. Could someone provide an example that works in gccas in release 1.9 for both defining which section the var is assigned to and defining the variables alignment? Also, is there another document that describes how you define sections

Vikram, I also agree with you. I understand that target-independent representation is very valuable and important for software compilation. However, when we are doing high-level synthesis (also called behavioral/architectural synthesis), the targeting architecture is also changing. That is, we need to do architecture exploration and the IR transfromation simultaneously. For example,

Yiping, Could you describe in a little more detail what your goals are? I agree with Reid and Misha that modifying the instruction definition is usually not advisable but to suggest alternatives, we would need to know more. Also, for some projects it could make sense to change the instruction set. --Vikram http://www.cs.uiuc.edu/~vadve http://llvm.cs.uiuc.edu/ On Oct 20, 2004, at 2:41 PM,

On Wed, Oct 20, 2004 at 11:59:45AM -0700, Yiping Fan wrote: > Yeah. We need to have more extra fields in the instruction. Fo > example, during high-level synthesis, we must schedule an instruction > to a certain control step (or cycle), and bind it to be execute on a > certain functional unit, etc. Since we're talking about "execution" and "scheduling", you

Yiping, If you are doing architectural synthesis, I do agree that you likely need to capture some operations in the instruction set, especially if you want to perform analyses and optimizations on those operations. Some specific comments: On Oct 20, 2004, at 6:04 PM, Yiping Fan wrote: > Vikram, >     I also agree with you. I understand that target-independent > representation is

Dear all, Recently I've wanted to add support for threads to LLVM (motivated by OpenMP, more or less), but before jumping in and implementing anything, I thought it might be a good idea to describe what I have in mind and ask for comments. Hence this email - if anyone has any comments, I'd be very glad to hear them. WHAT I'M PROPOSING: The addition of two instructions - fork

I have a question about GetElementPtr. Suppose I have an GetElementPtr Instruction GI: %reg = getelementptr %ST* %s, uint 1, ubyte 2, ubyte 1, uint 5, uint 13 I want to check if this is the reference of a component of a structure, how can I do that? Should I check which operand of this instruction is 'ubyte' type? How can I do that in code? should I use ubyte *a =

You are correct, ubyte 2 simply means 3rd element of the structure. This quantity is always constant (it specifies the field number), so we could have used any signed or unsigned integer type for it instead of ubyte. UByte means we are limited to at most 256 structure fields but it also makes the bytecode representation more compact. (To remove this restriction, we may migrate to UInt in the

FAIL: /usr/home/jeffc/llvm/obj/../test/Regression/Transforms/InstCombine/2004-11-27-SetCCForCastLargerAndConstant.ll: %Y = cast sbyte %SB to uint ; <uint> [#uses=1] %Y = cast sbyte %SB to int ; <int> [#uses=1] %Y = cast sbyte %SB to int ; <int> [#uses=1] %Y = cast ubyte %SB to uint ; <uint> [#uses=1] %Y = cast ubyte %SB to

LegalizeDAG.cpp SDOperand SelectionDAGLegalize::LegalizeOp(SDOperand Op) { case ISD::RET: Tmp1 = LegalizeOp(Node->getOperand(0)); // Legalize the chain. switch (Node->getNumOperands()) { case 2: // ret val [skipped] case 1: // ret void [skipped] default: { // ret <values> [skipped] Does it imply that a ret instruction may

Does our pass need to ensure that the new names it creates for the field allocations are, in fact, unique? -- Casey Carter Casey at Carter.net ccarter at uiuc.edu AIM: cartec69

Hello! I get some odd behaviour using my structs: "myKernelMap" = type {int (sbyte*)*, int ()*} "Kernel" = type {"myKernelMap"*} The second member ( int()* ) is a pointer to the %getchar() function. I want to call getchar using this function: int "callmyKernelgetchar_kernel"("Kernel"* "myKernel") { "PTRMAP" =

> Okay, I took a closer look at your output. > > I was correct in that gccas is attempting to assemble a native PPC > assembly language file. However, this appears to be happening because > the assembly file is generated by the GCC Makefiles for libgcc2 (in > llvm-gcc/gcc/config/rs6000/t-ppccomm, I think). > > The first thing I would try is Marco's suggestion: add

Hi all, I just checked in a series of patches that makes some substantial changes to the LLVM getelementptr instruction. In particular, in LLVM 1.2 and earlier, the getelementptr instruction required index operands for structure types to be 'ubyte' constants and index operands for sequential types to be 'long' values. This had several problems, most notably that it was