================
@@ -179,6 +179,13 @@ void sparc::getSparcTargetFeatures(const Driver &D, const
ArgList &Args,
Features.push_back("-hard-quad-float");
}
+ if (Arg *A = Args.getLastArg(options::OPT_mv8plus, options::OPT_mno_v8plus))
{
+ if (A->getOption().matches(options::OPT_mv8plus))
----------------
koachan wrote:
> AFAIK it is an ABI affecting flag, although I don't know if it changes
> anything except for ELF header's e_machine field compared to 32-bit V8/V9. It
> can't safely be ignored if we claim support for V8+. If we don't, and V8+ is
> otherwise compatible with 32-bit ABI, I think ignoring it and generating
> instructions should be fine, probably with a warning.
AFAICT the main ABI change is widening the G and O registers to 64-bits, which
is compatible with legacy ABI:
- The kernel handles saving and restoring those registers during context
switches, so it is out of scope for us (aside from setting the correct ELF
e_machine value so the kernel knows how much state to handle);
- The (non-reserved) G registers are volatile anyway, so any code should not
make assumptions about its value past a call or return;
- The O registers are widened too, however, during a call, the callee might
issue a `save` (which will result in the values being rotated - and truncated -
into the I registers), so 64-bit arguments need to be split into 2x32-bit pair,
just as in legacy ABI; and
- Similarly, the callee might put its return value in the I registers before
issuing a `restore`, so the caller will receive 64-bit returns as 2x32-bit
pairs, just as in legacy ABI.
> It could be helpful to have a draft that adds some V8+ support to the backend
> and the corresponding feature bits.
Backend bits are in #101367 (incl. ELF e_machine type setting), that should be
merged first before this PR.
https://github.com/llvm/llvm-project/pull/98713
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
