<div dir="ltr">On 11 November 2013 09:46, PaX Team <span dir="ltr"><<a href="mailto:pageexec@gmail.com" target="_blank">pageexec@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">now all this is very linux (and kernel context) specific so i don't know if</span><br></div>
you really need to worry about other use cases. of course there's the more<br>
generic gcc feature of being able to assign other registers to variables,<br>
not just the stack pointer. i don't know if clang/llvm wants to go there<br>
as it then brings up the whole -ffixed-REG/-fcall-saved-REG/-fcall-used-REG<br>
business as well ;).<br></blockquote><div></div></div><br></div><div class="gmail_extra">We already have -ffixed-r9 for ARM for similar reasons, but I think we would require an extensive discussion (like this one) to define if we want to have those options, lots of built-in intrinsics, or both. But, as you said, one thing at a time... ;)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I think there are clear reasons for Clang/LLVM to support the kernel, the issue is just finding the best solution for each problem. Because the kernel and GCC walked so closely for decades, some of the solutions weren't taken because it was the best, but because it was the simplest. If we do the same now, we'll never get rid of bad code on both kernels and compilers.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">The GCC folks are also taking a similar approach nowadays, and would be good to know what they think on the problems we're solving here.</div><div class="gmail_extra">
<br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>