search for: armgeninstrinfo

...is often more convenient to use def : Pat<>, and sometimes custom instruction selection is required. As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc lib/Target/ARM/ARMGenInstrInfo.inc:727 lib/Target/X86/X86GenInstrInfo.inc:920 I don't think more than half of those UnmodeledSideEffects flags should be there. I want to stop inferring instruction properties from patterns in TableGen. It has become very hard to read instruction definitions when some properties are inferre...

...st course of action. Having said that, we can always go back. So, I'm open to suggestions. I could start with only a few per arch, and then add as we see fit. My guess is that only ARMGenRegisterInfo.inc and ARMGenSubtargetInfo.inc would be a good start, with possibly ARMGenCallingConv.inc and ARMGenInstrInfo.inc being the next ones to add for Clang's benefit. That would mean separating the calls to tablegen() between CMakeLists.txt and CMakeTblgen.txt, but that's ok. cheers, --renato

...to use def : Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be there. > > > I want to stop inferring instruction properties from patterns in TableGen. It has become very hard to read instruction definitions wh...

...to use def : Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be there. > > > I want to stop inferring instruction properties from patterns in TableGen. It has become very hard to read instruction definitions wh...

On Mon, Jun 16, 2008 at 05:00:24PM +0100, Edd Barrett wrote: > On Thu, Jun 12, 2008 at 7:02 PM, Edd Barrett <vext01 at gmail.com> wrote: > > gcc4.2 works fine. > > But it only works fine for svn snapshots. Your most recent release > does not build on OpenBSD with gcc-4.2. > > llvm[3]: Building ARM.td instruction selector implementation with tblgen > assertion

...ef : > Pat<>, and sometimes custom instruction selection is required. > > As a result, many instructions are defined without a pattern, and we often > forget to set neverHasSideEffects = 1. > > $ grep -c UnmodeledSideEffects lib/Target/*/*GenInstrInfo.inc > lib/Target/ARM/ARMGenInstrInfo.inc:727 > lib/Target/X86/X86GenInstrInfo.inc:920 > > I don't think more than half of those UnmodeledSideEffects flags should be > there. > > > I want to stop inferring instruction properties from patterns in TableGen. > It has become very hard to read instruction definit...

On 9 March 2015 at 17:40, Renato Golin <renato.golin at linaro.org> wrote: > The only way I can think of solving this is to change how tablegen() > handles the file name, with some "if(IS_ABSOLUTE)", but looking > further, the file name is used to more than just a filename, and gets > included in some variables names, etc. Also, I can't add another > option to

...t;> non-terminator tBLXi. This looks wrong. Does anyone have any comments on >> this? > > Isn't it because one of the predicates is CPSR, which means it's a > conditional instruction, so not really a terminator? It is marked as a terminator in the table-gen output (ARMGenInstrInfo.inc): { 2399, 5, 1, 4, 355, 0|(1ULL<<MCID::Pseudo)|(1ULL<<MCID::Return)|(1ULL<<MCID::Barrier)|(1ULL<<MCID::MayLoad)|(1ULL<<MCID::Predicable)|(1ULL<<MCID::Terminator)|(1ULL<<MCID::Variadic)|(1ULL<<MCID::UnmodeledSideEffects)|(...

...ertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node type!"" f ailed: file "CodeGenDAGPatterns.cpp", line 932, function "ApplyTypeConstraints" gmake[3]: *** [/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM/Release/ ARMGenInstrInfo.inc.tmp] Abort trap (core dumped) gmake[3]: Leaving directory `/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Targe t/ARM' gmake[2]: *** [ARM/.makeall] Error 2 gmake[2]: Leaving directory `/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Targe t' gmake[1]: *** [Target/.makeall] Error 2 gmake[1]...

...sertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node type!"" failed: file "CodeGenDAGPatterns.cpp", line 934, function "ApplyTypeConstraints" gmake[3]: *** [/usr/ports/devel/llvm/w-llvm-2.3/llvm-2.3/lib/Target/ARM/Debug/ARMGenInstrInfo.inc.tmp] Abort trap (core dumped) Does this shed any light on the situation? Thanks

While building an OpenBSD port for LLVM 2.3 I encountered a few issues. The first one is that the system compiler $ gcc -v Reading specs from /usr/lib/gcc-lib/amd64-unknown-openbsd4.3/3.3.5/specs Configured with: Thread model: single gcc version 3.3.5 (propolice) Fails to build TableGen correctly which then crashes while processing the tables for ARM. I fixed this by using gcc 4.2.0 The

On Thu, Jun 12, 2008 at 7:02 PM, Edd Barrett <vext01 at gmail.com> wrote: > gcc4.2 works fine. But it only works fine for svn snapshots. Your most recent release does not build on OpenBSD with gcc-4.2. llvm[3]: Building ARM.td instruction selector implementation with tblgen assertion "getOperator()->isSubClassOf("SDNodeXForm") && "Unknown node

...ude SP; but from ARMv8 onwards, it does include it. RegClass membership is currently implemented as entirely static, driven by read-only TableGen'd tables and switch blocks encoding the various classes, subclasses, and their relationships. The approach I had taken in my patch was to include ARMGenInstrInfo.inc for a second time, after re-defining rGPRRegClassID to use a different RegClass in the same instructions. Then, Thumb2InstrInfo constructor overrides the MCInstrInfo that it inherited from ARMBaseInstrInfo with the "patched" one. (This "patching", still, happens at compile-t...

Hello, The function ARMBaseInstrInfo::AnalyzeBranch contains the following piece of code: } else if (I->isReturn()) { // Returns can't be analyzed, but we should run cleanup. CantAnalyze = !isPredicated(I); } else { This could lead to cases where for a block that ends with a conditional return, AnalyzeBranch returns false (i.e. analyzed), both TBB and FBB are

...et/ARM/.gitignore b/lib/Target/ARM/.gitignore new file mode 100644 index 0000000..885bdf1 --- /dev/null +++ b/lib/Target/ARM/.gitignore @@ -0,0 +1,13 @@ +ARMGenAsmMatcher.inc +ARMGenAsmWriter.inc +ARMGenCallingConv.inc +ARMGenCodeEmitter.inc +ARMGenDAGISel.inc +ARMGenEDInfo.inc +ARMGenFastISel.inc +ARMGenInstrInfo.inc +ARMGenMCCodeEmitter.inc +ARMGenMCPseudoLowering.inc +ARMGenRegisterInfo.inc +ARMGenSubtargetInfo.inc +ARMGenDisassemblerTables.inc diff --git a/lib/Target/CellSPU/.gitignore b/lib/Target/CellSPU/.gitignore new file mode 100644 index 0000000..6d3f2d2 --- /dev/null +++ b/lib/Target/CellSPU/.giti...

Hi there, I am a student considering a compiler design based dissertation with llvm. I am having problems building llvm on OpenBSD-current. I hope to make a port of llvm for OpenBSD once I have figured out how to build it. Observe: llvm[3]: Compiling Deserialize.cpp for Release build In file included from /home/edd/llvm/llvm-2.3/include/llvm/Bitcode/BitstreamRead er.h:18, from