search for: x86gensubtargetinfo

...na 10.15. Now every time I "make clang", the building systems rebuilds all the .inc files generated by cmake, which essentially rebuilds all the tablegen files in llvm, although I did not change any of the tablegen files. The building is unnecessary and slow, especially when it builds the X86GenSubtargetInfo.inc. Is there a way to prevent cmake generating Makefiles that rebuilds all the tablegen files? Here is my command line to run cmake for generating Makefiles: cmake -G “Unix Makefiles” -DLLVM_TARGETS_TO_BUILD=“X86" -DCMAKE_BUILD_TYPE=Debug $(LLVM_SRC) The cmake version is 3.13.4. And I did...

...000000..13e4a62 --- /dev/null +++ b/lib/Target/X86/.gitignore @@ -0,0 +1,11 @@ +X86GenAsmMatcher.inc +X86GenAsmWriter.inc +X86GenAsmWriter1.inc +X86GenCallingConv.inc +X86GenDAGISel.inc +X86GenDisassemblerTables.inc +X86GenEDInfo.inc +X86GenFastISel.inc +X86GenInstrInfo.inc +X86GenRegisterInfo.inc +X86GenSubtargetInfo.inc diff --git a/lib/Target/XCore/.gitignore b/lib/Target/XCore/.gitignore new file mode 100644 index 0000000..9541ccb --- /dev/null +++ b/lib/Target/XCore/.gitignore @@ -0,0 +1,6 @@ +XCoreGenAsmWriter.inc +XCoreGenCallingConv.inc +XCoreGenDAGISel.inc +XCoreGenInstrInfo.inc +XCoreGenRegisterInfo.in...

hacker cling wrote: > Hello all, > I was playing with LLVM pass. I changed the > lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make > install the pass and use an example test1.c to see whether it works or > not. When I run example using the following command: > clang -emit-llvm test1.c -c -o test1.bc > opt -load

Hello all, I was playing with LLVM pass. I changed the lib/Transforms/Hello/Hello.cpp 's content to be my own pass. Then I make install the pass and use an example test1.c to see whether it works or not. When I run example using the following command: clang -emit-llvm test1.c -c -o test1.bc opt -load ../build_llvm/Debug+Asserts/lib/LLVMHello.so -hello < test1.bc > /dev/null It

Hello all, I've been working for the last month or so on a comprehensive mitigation approach to variant #1 of Spectre. There are a bunch of reasons why this is desirable: - Critical software that is unlikely to be easily hand-mitigated (or where the performance tradeoff isn't worth it) will have a compelling option. - It gives us a baseline on performance for hand-mitigation. - Combined