similar to: llvm-3.6 MCAsmParser x64 Error "invalid operand for instruction" when msb set

Hi All, I tryed to create a global structured derived declaration in my compiler by: StructType *st = StructType(getGlobalContext(), elements, false); In dump module i didn't find any code needed to declare a new user data type. Is there a instruction to add this class into current module? Cheers, Manuele

Hi, I test your code and it works!!! but I didn't understand if "create a function" it necessary for my aims. What I tried to do is declare a structured to allow after declaration global or local structured variables. How I can I do? Thanks, Manuele Il 31/01/2013 10:14, Garba,Peter ha scritto: > Hi, > > that's what I'm doing ... > > //Init the struct type

Hi everyone. We're interested in contributing a Hexagon assembler to MC and we're looking for comments on a good way to integrate the grammar in to the infrastructure. We rely on having a robust assembler because we have a large base of developers that write in assembly due to low power requirements for mobile devices. We put in some C-like concepts to make the syntax easier and this

Hi all, I learned of LLVM a couple of days ago: <http://groups.google.co.nz/groups?selm=pan.2004.12.18.11.29.33.33249%40consulting.net.nz> <http://groups.google.co.nz/groups?th=608e6e38e496f09d> (I posted a tail call followup which is missing from the archive) Jestingly, LLVM developers appear intent upon nothing short of world domination. Not only have you done an end run around

Hi Reid Spencer, > CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure > make > > and was able to reproduce the problem. Not sure what's up with that but > as Misha pointed out, llvmgcc isn't any "particular" version of 3.4, its > just 3.4ish. I also concur with him that you should file a bug and > attach the pre-processed source to it. You can get that with

Adam, I recant my previous message. I built FreeType with GCC not LLVMGCC by accident (I shoulda checked!). The thing is, FreeType's makefiles don't respect environment variables. So, I did this: CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure make and was able to reproduce the problem. Not sure what's up with that but as Misha pointed out, llvmgcc isn't any

On Sun, 2004-12-19 at 20:20, Adam Warner wrote: > Hi all, Hi Adam, > > I learned of LLVM a couple of days ago: > <http://groups.google.co.nz/groups?selm=pan.2004.12.18.11.29.33.33249%40consulting.net.nz> > <http://groups.google.co.nz/groups?th=608e6e38e496f09d> > (I posted a tail call followup which is missing from the archive) > Jestingly, LLVM developers

On Sun, 2004-12-19 at 22:52, Adam Warner wrote: > Hi Reid Spencer, > > > CC=/path/to/llvmgcc CXX=/path/to/llvmg++ configure > > make > > > > and was able to reproduce the problem. Not sure what's up with that but > > as Misha pointed out, llvmgcc isn't any "particular" version of 3.4, its > > just 3.4ish. I also concur with him that you

Hello everyone, while working on a simple PE-Parser, using the llvm/Support/COFF.h Header, to validate if a given File is a PE-File and to read the Machine Field I was experiencing some troubles. It seemed the Fields were somehow misaligned and I could pinpoint the source of the misalignment to be the "NumberOfSections" field inside the "header"-struct (a.k.a.

Hello, LLVM MC blog post <http://blog.llvm.org/2010/04/intro-to-llvm-mc-project.html> explains fairly well how the backend MC project is working. However, it's not clear to me how LLVM converts an assembly file (.s) to an object file. The driver --verbose option is not giving me much information as well. I want to know the flow. Like, What CodeGen phases does this file pass through? Is

Compile the following functions with "-O3 -target i386-win32" (see <https://godbolt.org/z/exmjWY>): __int64 __fastcall div(__int64 foo, __int64 bar) { return foo / bar; } On the left the generated code; on the right the expected, properly optimised code: push dword ptr [esp + 16] | push dword ptr [esp + 16] | push dword ptr [esp + 16] |

Hi, The x86 CPU IMUL instruction has forms such as: IMUL reg EDX:EAX ← EAX ∗ reg reg, EAX and EDX are 32bit registers. How can I represent this sort of instruction in LLVM IR ? It is really a 32bit * 32 bit = 64 bit, but no LLVM IR exists to do that. Or, a similar question: What LLVM IR would produce this IMUL instruction form? For context, I am writing a x86 to LLVM IR decompiler, so wish to

Passing an assembly file to clang does not go through any CodeGen phases. It operates entirely in the MC layer. No MachineFunctions will be created. It just runs it through the MCAsmParser. Most of the setup for this is in clang's tools/driver/cc1as_main.cpp in the function ExecuteAssembler ~Craig On Thu, May 10, 2018 at 1:32 PM Soham Sinha via llvm-dev < llvm-dev at lists.llvm.org>

I noticed that fourinarow is one of the programs in which LLVM is much slower than GCC, so I decided to take a look and see why that is so. The program has many loops that look like this: #define ROWS 6 #define COLS 7 void init_board(char b[COLS][ROWS+1]) { int i,j; for (i=0;i<COLS;i++) for (j=0;j<ROWS;j++) b[i][j]='.';

The saga continues. I've been tracking the interface changes and merging them with the refactoring work I'm doing. I got as far as building stage3 of llvm-gcc but the object files from stage2 and stage3 differ: warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs (Are the above two ok?) The list below is clearly bad. I think it's every object file in the

As part of trying to fix PR30610 (ThinLTO with module inline asm), I wanted to add an assert that we have a Target and an MCAsmParser when we have non-null module inline asm in IRObjectFile::CollectAsmUndefinedRefs. Otherwise it silently fails to parse the module inline asm, which I initially found when trying to add an 'opt' based test for my fix (because 'opt' wasn't

On Mon, 21 Feb 2005, Jeff Cohen wrote: > I noticed that fourinarow is one of the programs in which LLVM is much slower > than GCC, so I decided to take a look and see why that is so. The program > has many loops that look like this: > > #define ROWS 6 > #define COLS 7 > > void init_board(char b[COLS][ROWS+1]) > { > int i,j; > > for

Sorry, I thought I was running selection dag isel but I screwed up when trying out the really big array. You're right, it does clean it up except for the multiplication. So LoopStrengthReduce is not ready for prime time and doesn't actually get used? I might consider whipping it into shape. Does it still have to handle getelementptr in its full generality? Chris Lattner wrote:

Compile the following functions with "-O3 -target i386" (see <https://godbolt.org/z/VmKlXL>): long long div(long long foo, long long bar) { return foo / bar; } On the left the generated code; on the right the expected, properly optimised code: div: # @div push ebp | mov ebp, esp | push dword ptr [ebp + 20] | push

Adam sent me his tar file and only one file in it needs to be attached to a bug report, and it's only about 260KB. The initialization that causes the errors is below. I'm sure I can prune it down significantly. static const FT_Frame_Field header_fields[] = { { ft_frame_start, 0, 54 }, { ft_frame_ulong_be, (FT_Byte)sizeof ( ((TT_Header*)0)->Table_Version ),