Dale,
The user can specify the "fastcall" and "stdcall" attributes, and it
looks to me like llvm-gcc honors that. Certainly it should.
fastcall and stdcall are specific calling conventions. They are not
connected with fastcc at all.
— Gordon
fastcall != fastcc. fastcall is a well defined convention on x86 that has very specific ABI requirements. fastcc, on the other hand, is an LLVM thing, and LLVM is allowed to "innovate" on the abi where it wants to.
There is no requirement for LLVM to handle fastcc and fastcall the same.
-Chris
I see. Could we please change its name then? The .ll file uses
x86_fastcallcc for fastcall, for an additional level of confusion.
We can set a policy of treating fastcc external functions
as c functions. Then there is no chance of introducing ABI
incompatibility.this means limiting tail call opt to protected/invisible functions
within a module?
a little limiting i think.
It makes sense to be extra careful at this point. The policy can be changed when we enable tail call optimization by default.
but i think if it is documented that there will be a incompatibility
between
modules compiled with tailcallopt on/off that is okay?
and this would only happen if someone other than llvm-gcc used llvm
as a backend
anyway.
Documentation isn't going to be enough. We will do everything possible to ensure there isn't abi incompatibility. But at this point, it's important the patch does not impact codegen in any way when tail call optimization is off. This allows us to get a true sense of the performance impact.
Evan
well then back to my original question? evan? chris?
We can set a policy of treating fastcc external functions
as c functions. Then there is no chance of introducing ABI
incompatibility.
this means limiting tail call opt to protected/invisible functions within a module?
a little limiting i think.
but i think if the incompatibility between modules compiled with tailcallopt on/off is documented
then this will be okay?
and this would only happen if someone other than llvm-gcc used llvm as a backend
anyway.
so i will make tailcallopt toggle the stack adjusting behaviour. with llvm-gcc this won't be a problem
and if someone other using llvm as a backend runs into a problem than there is the documentation
and the maillist that will help.
is that okay?
to me like llvm-gcc honors that. Certainly it should.
This would imply one fastcc abi (callee pops args on return) to rule
them all?
That is only if fastcall translates to llvm fastcc of course.fastcall != fastcc. fastcall is a well defined convention on x86 that has
very specific ABI requirements. fastcc, on the other hand, is an LLVM
thing, and LLVM is allowed to "innovate" on the abi where it wants to.There is no requirement for LLVM to handle fastcc and fastcall the same.
okay
okay then i'll make tailcallopt switch stack adjusting behaviour?
Yes please.
Evan
okay :^)
Dale,
I see. Could we please change its name then?
fastcc?
The .ll file uses
x86_fastcallcc for fastcall, for an additional level of confusion.
It was made intentionally to outline the target-specific nature of CC.
Just chiming in here since a stated goal is something I'm working on. Tail calls and calling conventions aren't yet a problem for me, but they're definitely on the radar.
As context, my current goal is to support the existing Ocaml runtime with my LLVM-based compiler, despite the peculiarities of the runtime.
Ocaml supports tail calls by never pushing arguments onto the stack. On x86, the first five arguments are passed using %eax, %ebx, %ecx, %edx, and %esi (left to right) and the sole return value is passed in %eax. (Ocaml never performs dynamic allocas, and so always performs frame pointer elimination. Floats are passed by reference.) The front-end will address the case of additional arguments.
For my implementation of ocamlopt, the most useful LLVM features in this area would be would be support for the above cc, and tail calls for the inreg case. The former seems to be fairly well trivial; hopefully your work could be tweaked to accomplish the latter.
— Gordon
I think Dale’s confusion is that “fast(call|cc)*” names two very different conventions, and he’s saying that “internalcc” or something would perhaps be a better name for fastcc, to differentiate it from x86 fastcall.
— Gordon
i guess there will have to be a ocamlcc calling convention and some tweaks
to X86RegisterInfo.cpp to return the correct calleesaved registers.
i guess most of my code could be reused for the tail call stuff.
i would be glad to help if/when you need it
regards
arnold
Another round 
Sadly not beer.
tested against r42630 darwin-x86:
SPASS llc-beta still fails
thanks for the patience
Yes please.
okay then i'll make tailcallopt switch stack adjusting behaviour?
the patch for the test suite (when/if it's needed) would be something like:
>>>>>
--- Makefile.programs (revision 42630)
+++ Makefile.programs (working copy)
@@ -221,7 +221,8 @@
LLCBETAOPTION := -sched=simple
endif
ifeq ($(ARCH),x86)
-LLCBETAOPTION := -enable-x86-conv-3-addr
+LLCBETAOPTION := -tailcallopt
+# -enable-x86-conv-3-addr
#-regalloc=local -fast
#-disable-rematerialization
#-disable-fp-elim
>>>>>
gee i am tired really have to go to bed now.
regards
tailcall-r42653-llvm.patch (66.5 KB)
Ok. Like I said, I am not too concerned with one or two llcbeta failures. That's expected.
Thx,
Evan
There have been some changes in X86RegisterInfo.cpp that make my last patch not merge.
Also there was an error in my code concerning how inreg parameters were lowered.
the latest version of the patch does not fail the SPASS llc-beta test anymore (darwin-x86).
if/when someone has the time to look at it - i would be happy to mail it. i think i should no longer clobber the mailing list with my patches
regards arnold
There have been some changes in X86RegisterInfo.cpp that make my last
patch not merge.
Sorry, I know it's a moving target.
Also there was an error in my code concerning how inreg parameters
were lowered.the latest version of the patch does not fail the SPASS llc-beta test
anymore (darwin-x86).
Very nice.
if/when someone has the time to look at it - i would be happy to mail
it. i think i should no longer clobber the mailing list with my
patches
Send it my way please.
Thanks,
Evan
Incidentally, if you're worried about spamming llvmdev, feel free to use llvm-commits. People who subscribe there have already signed up for a ton of mail , so detailed discussion of patches is just fine there. llvmdev is a good place for high level discussions and various questions of course, as it is more widely read.
FWIW, there are currently 62 llvm-commits subscribers, 407 llvmdev subscribers, and 813 llvm-announce subscribers.
-Chris
FWIW, there are currently 62 llvm-commits subscribers
plus those that read it via gmane.org, like me