search for: anyregcc

...do a lot of things which increases register pressure and spills %db br label %main_execution_loop; main_execution_loop: ; We do instruction dispatch here ... opcode_a: %name0 = ... ; Use the database to look up %name0 and then overwrite the patchpoint ; with a direct call tail call anyregcc void (i64, i32, i8*, i32, ...)* @llvm.experimental.patchpoint.void(i64 4711, i32 16, @lookup_and_patch, i32 0, some_type %name0, some_type %db) ... %name1 = ... ; Use the database to look up %name1 and then overwrite the patchpoint ; with a direct...

...otherwise the client's patchpoint-initialization logic will have to do that; that's fine, but it means that one has to reserve nops for spilling in every patchpoint, whereas LLVM will emit the spill code when necessary. There was some discussion about what the behavior should be if you use anyregcc, since in that case it seems reasonable to receive a caller-save register if you are interested in using it inside the patchpoint. My thoughts are that in that case you might be better off including the value as part of the function arguments instead of the stackmap/deopt arguments. I think Philip...

...as a bunch of early-clobber registers. This last solution would not allow both live-on-return and live-on-call operands in the same call. Hopefully there’s something more clever that I haven’t thought of yet. >> There was some discussion about what the behavior should be if you use >> anyregcc, since in that case it seems reasonable to receive a >> caller-save register if you are interested in using it inside the >> patchpoint. My thoughts are that in that case you might be better off >> including the value as part of the function arguments instead of the >> stac...

...hat registers stay live across the call. But in general, I see your point. You get around that by defining a new calling convention. Each patchpoint intrinsic call can be marked with a different calling convention if you choose. For example, we'll be adding a dynamic calling convention called AnyRegCC. You can use that to effectively specify the number of arguments that you want to force into registers. The stack map will tell you which registers were used for arguments. The "call" will preserves most registers, but clobbers one register (on x86) for use within the code. Another poten...

...oss the call. But in general, I see your point. > > You get around that by defining a new calling convention. Each > patchpoint intrinsic call can be marked with a different calling > convention if you choose. For example, we'll be adding a dynamic > calling convention called AnyRegCC. You can use that to effectively > specify the number of arguments that you want to force into registers. > The stack map will tell you which registers were used for arguments. > The "call" will preserves most registers, but clobbers one register > (on x86) for use within...

Adding Gael as someone who has previously discussed vmkit topics on the list. Since I'm assuming this is where the GC support came from, I wanted to draw this conversation to the attention of someone more familiar with the LLVM implementation than myself. On 10/22/13 4:18 PM, Andrew Trick wrote: > On Oct 22, 2013, at 3:08 PM, Filip Pizlo <fpizlo at apple.com > <mailto:fpizlo