<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Jun 4, 2015 at 2:31 PM Alexei Starovoitov <<a href="mailto:alexei.starovoitov@gmail.com">alexei.starovoitov@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Thu, Jun 4, 2015 at 2:17 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>> wrote:<br>
><br>
>> On Jun 4, 2015, at 2:12 PM, Alexei Starovoitov <<a href="mailto:alexei.starovoitov@gmail.com" target="_blank">alexei.starovoitov@gmail.com</a>> wrote:<br>
>><br>
>> On Thu, Jun 4, 2015 at 2:09 PM, Quentin Colombet <<a href="mailto:qcolombet@apple.com" target="_blank">qcolombet@apple.com</a>> wrote:<br>
>>><br>
>>> On Jun 4, 2015, at 1:53 PM, Alexei Starovoitov<br>
>>> <<a href="mailto:alexei.starovoitov@gmail.com" target="_blank">alexei.starovoitov@gmail.com</a>> wrote:<br>
>>><br>
>>> On Thu, Jun 4, 2015 at 12:24 PM, Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank">echristo@gmail.com</a>><br>
>>> wrote:<br>
>>><br>
>>> It doesn't look like anyone actually approved this? (I know, it was in my<br>
>>> list of things to look at :)<br>
>>><br>
>>><br>
>>> nope. It started to bit rot too quickly, so I pushed it.<br>
>>><br>
>>><br>
>>> Please don’t do that. Unless I am mistaken, the review was out only for a<br>
>>> couple of days.<br>
>>> Here is the review policy, if you want more information.<br>
>>> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_docs_DeveloperPolicy.html-23code-2Dreviews&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=mQ4LZ2PUj9hpadE3cDHZnIdEwhEBrbAstXeMaFoB9tg&m=9-ro6dAIAN1K4no7VaCzVHixsRQmcNIBmyTHFe-_Y5g&s=f6uwn9DnG-_x7BSwjcdKCI8XRhD530AdK7snZhtIq4w&e=" target="_blank">http://llvm.org/docs/DeveloperPolicy.html#code-reviews</a><br>
>><br>
>> hmm, I'm exactly doing the following part:<br>
>> "(or changes where the developer owns the component) can be reviewed<br>
>> after commit."<br>
><br>
> Well, in that case, don’t post a review request in the first place :).<br>
<br>
:)<br>
well I mainly wanted to get feedback for logic that<br>
-march=bpf does _host_ endian.<br>
I don't think any other backend does things like that.<br>
What the patch does:<br>
-march=bpf -> host endian<br>
-march=bpf_le -> little endian<br>
-march=bpf_be -> big endian<br>
<br></blockquote><div><br></div><div>So, part of why I was going to review the Triple part of it is that the naming convention for bpf big and little endian explicit triples doesn't match the same convention for every other target. So, what references do you have for these outside of llvm? I'd prefer to copy the existing nomenclature if there's no compelling reason otherwise.</div><div><br></div><div>Thanks.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
the typical scenario is to compile it on the host,<br>
load into the kernel and run it there.<br>
So from ease-of-use point of view it's the best<br>
(this behavior is specifically what s390 folks have asked)<br>
but since no other backend does host-endian,<br>
I wanted to double check and/or argue about it :)<br>
<br>
For llvm+bpf backend users it's easier to git pull from main<br>
tree instead of applying my one-of patches that I'm sending<br>
them over email and they bit-rot too quickly and fail to apply.<br>
</blockquote></div></div>