Changes in stackmap-nops.ll

1d641daf - [X86] Adjust nop emission by compiler to consider target decode limitations

Sat, 11 Jan 2020 16:41:35 +0000

[X86] Adjust nop emission by compiler to consider target decode limitationsThe primary motivation of this change is to bring the code more closely in sync behavior wise with the assembler's version of nop emission. I'd like to eventually factor them into one, but that's hard to do when one has features the other doesn't.The longest encodeable nop on x86 is 15 bytes, but many processors - for instance all intel chips - can't decode the 15 byte form efficiently. On those processors, it's better to use either a 10 byte or 11 byte sequence depending. List of files: /llvm-project-15.0.7/llvm/test/MC/X86/stackmap-nops.ll

b7cef81f - Replace "no-frame-pointer-*" function attributes with "frame-pointer"

Mon, 14 Jan 2019 10:55:55 +0000

Replace "no-frame-pointer-*" function attributes with "frame-pointer"Part of the effort to refactoring frame pointer code generation. We usedto use two function attributes "no-frame-pointer-elim" and"no-frame-pointer-elim-non-leaf" to represent three kinds of framepointer usage: (all) frames use frame pointer, (non-leaf) frames useframe pointer, (none) frame use frame pointer. This CL makes the ideaexplicit by using only one enum function attribute "frame-pointer"Option "-frame-pointer=" replaces "-disable-fp-elim" for tools such asllc."no-frame-pointer-elim" and "no-frame-pointer-elim-non-leaf" are stillsupported for easy migration to "frame-pointer".tests are mostly updated with// replace command line args ‘-disable-fp-elim=false’ with ‘-frame-pointer=none’grep -iIrnl '\-disable-fp-elim=false' * | xargs sed -i '' -e "s/-disable-fp-elim=false/-frame-pointer=none/g"// replace command line args ‘-disable-fp-elim’ with ‘-frame-pointer=all’grep -iIrnl '\-disable-fp-elim' * | xargs sed -i '' -e "s/-disable-fp-elim/-frame-pointer=all/g"Patch by Yuanfang Chen (tabloid.adroit)!Differential Revision: https://reviews.llvm.org/D56351llvm-svn: 351049 List of files: /llvm-project-15.0.7/llvm/test/MC/X86/stackmap-nops.ll

23af6484 - [opaque pointer type] Add textual IR support for explicit type parameter to the call instruction

Thu, 16 Apr 2015 23:24:18 +0000

[opaque pointer type] Add textual IR support for explicit type parameter to the call instructionSee r230786 and r230794 for similar changes to gep and loadrespectively.Call is a bit different because it often doesn't have a single explicittype - usually the type is deduced from the arguments, and just thereturn type is explicit. In those cases there's no need to change theIR.When that's not the case, the IR usually contains the pointer type ofthe first operand - but since typed pointers are going away, thatrepresentation is insufficient so I'm just stripping the "pointerness"of the explicit type away.This does make the IR a bit weird - it /sort of/ reads like the type ofthe first operand: "call void () %x(" but %x is actually of type "void()*" and will eventually be just of type "ptr". But this seems not toobad and I don't think it would benefit from repeating the type("void (), void () * %x(" and then eventually "void (), ptr %x(") as hasbeen done with gep and load.This also has a side benefit: since the explicit type is no longer apointer, there's no ambiguity between an explicit type and a functionthat returns a function pointer. Previously this case needed an explicittype (eg: a function returning a void() function was written as"call void () () * @x(" rather than "call void () * @x(" because of theambiguity between a function returning a pointer to a void() functionand a function returning void).No ambiguity means even function pointer return types can just bewritten alone, without writing the whole function's type.This leaves /only/ the varargs case where the explicit type is required.Given the special type syntax in call instructions, the regex-fu usedfor migration was a bit more involved in its own unique way (as everyone of these is) so here it is. Use it in conjunction with the apply.shscript and associated find/xargs commands I've provided in rr230786 tomigrate your out of tree tests. Do let me know if any of this doesn'tcover your cases & we can iterate on a more general script/regexes tohelp others with out of tree tests.About 9 test cases couldn't be automatically migrated - half of thosewere functions returning function pointers, where I just had to manuallydelete the function argument types now that we didn't need an explicitfunction type there. The other half were typedefs of function types usedin calls - just had to manually drop the * from those.import fileinputimport sysimport repat = re.compile(r'((?:=|:|^|\s)call\s(?:[^@]*?))(\s*$|\s*(?:(?:\[\[[a-zA-Z0-9_]+\]\]|[@%](?:(")?[\\\?@a-zA-Z0-9_.]*?(?(3)"|)|{{.*}}))(?:$|$)|undef|inttoptr|bitcast|null|asm).*$)')addrspace_end = re.compile(r"addrspace\(\d+$\s*\*$")func_end = re.compile("(?:void.*|\)\s*)\*$")def conv(match, line): if not match or re.search(addrspace_end, match.group(1)) or not re.search(func_end, match.group(1)): return line return line[:match.start()] + match.group(1)[:match.group(1).rfind('*')].rstrip() + match.group(2) + line[match.end():]for line in sys.stdin: sys.stdout.write(conv(re.search(pat, line), line))llvm-svn: 235145 List of files: /llvm-project-15.0.7/llvm/test/MC/X86/stackmap-nops.ll

98c3c0f3 - [X86] Add comments to clarify some non-obvious lines in the stackmap-nops.ll

Fri, 25 Jul 2014 04:50:08 +0000

[X86] Add comments to clarify some non-obvious lines in the stackmap-nops.lltestcases.Based on code review from Philip Reames. Thanks Philip!llvm-svn: 213923 List of files: /llvm-project-15.0.7/llvm/test/MC/X86/stackmap-nops.ll

f49bc3f1 - [X86] Optimize stackmap shadows on X86.

Thu, 24 Jul 2014 20:40:55 +0000

[X86] Optimize stackmap shadows on X86.This patch minimizes the number of nops that must be emitted on X86 to satisfystackmap shadow constraints.To minimize the number of nops inserted, the X86AsmPrinter now records thesize of the most recent stackmap's shadow in the StackMapShadowTracker class,and tracks the number of instruction bytes emitted since the that stackmapinstruction was encountered. Padding is emitted (if it is required at all)immediately before the next stackmap/patchpoint instruction, or at the end ofthe basic block.This optimization should reduce code-size and improve performance for peopleusing the llvm stackmap intrinsic on X86.llvm-svn: 213892 List of files: /llvm-project-15.0.7/llvm/test/MC/X86/stackmap-nops.ll

e8cba373 - Grow the stackmap/patchpoint format to hold 64-bit IDs.

Fri, 13 Dec 2013 18:37:10 +0000

Grow the stackmap/patchpoint format to hold 64-bit IDs.llvm-svn: 197255 List of files: /llvm-project-15.0.7/llvm/test/MC/X86/stackmap-nops.ll

c4c9b371 - [Stackmap] Specify the triple and cpu to fix the unit test.

Wed, 04 Dec 2013 01:02:37 +0000

[Stackmap] Specify the triple and cpu to fix the unit test.llvm-svn: 196339 List of files: /llvm-project-15.0.7/llvm/test/MC/X86/stackmap-nops.ll

17e0d9ee - [Stackmap] Emit multi-byte nops for X86.

Wed, 04 Dec 2013 00:39:08 +0000

[Stackmap] Emit multi-byte nops for X86.llvm-svn: 196334 List of files: /llvm-project-15.0.7/llvm/test/MC/X86/stackmap-nops.ll