Add initial support for *-*-nacl target.

Add initial support for *-*-nacl target.

This is supposed to go to the mainstream LLVM tree.

[pdox, 2011-07-23 05:24:28]

krasin,

While upstreaming is a good thing, I'm not sure it is a good idea to submit such
tiny patches to upstream.  We have over 10,000 lines of code to upstream, and so
having patches which are only a couple of lines each is wasteful.

Also, while this patch does the same thing as changes in our repository, it
appears to be a reimplementation. If this gets pulled in during a merge, strange
things will happen. We should keep our local repository in sync with what we
wish to upstream, so that the merges are trivial.

t is necessary to do this.

[pdox, 2011-07-23 05:25:31]

Please ignore the last line of the previous comment, copy & paste error.

[krasin, 2011-07-23 09:00:41]

David,

> 
> While upstreaming is a good thing, I'm not sure it is a good idea to submit
such tiny patches to upstream.
This CL is reimplementation of r134282:
http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/94313

The reasons to keep the first change so tiny:
- this CL is very similar to the CL already accepted to the mainline , so that I
have a minimal probability to get it rejected
- it aims to test the process, become familiar with people and tools. In fact,
this CL has already attracted the attention of the LLVM team at Google (they are
LLVM committers and already pointed me to the lack of "LLVM code-review
culture". I have a lunch with one of them next week).

Obsolete reason:
- Once I would have 3 small changes to LLVM committed (adding NaCl OS, adding
NaCl architectures: bitcode, x86_64, i686, ARMv7 and a change to ./configure to
let it work with target_triple=bitcode-none-nacl, I planned to switch to Clang
changes which don't interfere with the existing code base.

>We have over 10,000 lines of code to upstream, and so
> having patches which are only a couple of lines each is wasteful.
The good news about all this idea is that I can always merge several tiny
patches into the larger one to make the process of review faster.

At the same time, it would be a hard time to convince them to review the CL if
it's the first in the series and it has the delta of 1000+ lines of code.

Anyway, I don't feel strong about the plan and I'd like to hear the feedback
from other LLVM/Google committers first.

> 
> Also, while this patch does the same thing as changes in our repository, it
> appears to be a reimplementation. If this gets pulled in during a merge,
strange
> things will happen. We should keep our local repository in sync with what we
> wish to upstream, so that the merges are trivial.
Sure. I'm in charge to make changes to our patch queue if my patch for some
reason is not literally the same. That will help us to avoid merge conflicts
(surely, I don't want to make problems for you)

Again: it's all about my original plan, I would not go into the discussion much
further, because I'm a n00b for LLVM and mostly I would like to hear than to
speak for now. 

Ivan

[sehr (please use chromium), 2011-07-25 22:28:49]

It seems to me that getting our build target stuff upstream soon would be a
good thing.  I agree we have a lot to get up there, but this seems a small,
but relevant, start.

David

On Sat, Jul 23, 2011 at 2:00 AM, <krasin@google.com> wrote:

> David,
>
>
>
>  While upstreaming is a good thing, I'm not sure it is a good idea to
>> submit
>>
> such tiny patches to upstream.
> This CL is reimplementation of r134282:
>
http://permalink.gmane.org/**gmane.comp.compilers.llvm.cvs/**94313<http://per...
>
> The reasons to keep the first change so tiny:
> - this CL is very similar to the CL already accepted to the mainline , so
> that I
> have a minimal probability to get it rejected
> - it aims to test the process, become familiar with people and tools. In
> fact,
> this CL has already attracted the attention of the LLVM team at Google
> (they are
> LLVM committers and already pointed me to the lack of "LLVM code-review
> culture". I have a lunch with one of them next week).
>
> Obsolete reason:
> - Once I would have 3 small changes to LLVM committed (adding NaCl OS,
> adding
> NaCl architectures: bitcode, x86_64, i686, ARMv7 and a change to
> ./configure to
> let it work with target_triple=bitcode-none-**nacl, I planned to switch to
> Clang
> changes which don't interfere with the existing code base.
>
>
>  We have over 10,000 lines of code to upstream, and so
>> having patches which are only a couple of lines each is wasteful.
>>
> The good news about all this idea is that I can always merge several tiny
> patches into the larger one to make the process of review faster.
>
> At the same time, it would be a hard time to convince them to review the CL
> if
> it's the first in the series and it has the delta of 1000+ lines of code.
>
> Anyway, I don't feel strong about the plan and I'd like to hear the
> feedback
> from other LLVM/Google committers first.
>
>
>
>  Also, while this patch does the same thing as changes in our repository,
>> it
>> appears to be a reimplementation. If this gets pulled in during a merge,
>>
> strange
>
>> things will happen. We should keep our local repository in sync with what
>> we
>> wish to upstream, so that the merges are trivial.
>>
> Sure. I'm in charge to make changes to our patch queue if my patch for some
> reason is not literally the same. That will help us to avoid merge
> conflicts
> (surely, I don't want to make problems for you)
>
> Again: it's all about my original plan, I would not go into the discussion
> much
> further, because I'm a n00b for LLVM and mostly I would like to hear than
> to
> speak for now.
>
> Ivan
>
>
>
>
>
http://codereview.chromium.**org/7484050/<http://codereview.chromium.org/7484...
>
> --
> You received this message because you are subscribed to the Google Groups
> "Native-Client-Reviews" group.
> To post to this group, send email to native-client-reviews@**
> googlegroups.com <native-client-reviews@googlegroups.com>.
> To unsubscribe from this group, send email to native-client-reviews+**
>
unsubscribe@googlegroups.com<native-client-reviews%2Bunsubscribe@googlegroups...
> .
> For more options, visit this group at http://groups.google.com/**
>
group/native-client-reviews?**hl=en<http://groups.google.com/group/native-client-reviews?hl=en>
> .
>
>

-- 
You received this message because you are subscribed to the Google Groups
"Native-Client-Reviews" group.
To post to this group, send email to native-client-reviews@googlegroups.com.
To unsubscribe from this group, send email to
native-client-reviews+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/native-client-reviews?hl=en.

[jvoung - send to chromium..., 2011-08-08 20:36:46]

http://codereview.chromium.org/7484050/diff/1/autoconf/configure.ac
File autoconf/configure.ac (right):

http://codereview.chromium.org/7484050/diff/1/autoconf/configure.ac#newcode303
autoconf/configure.ac:303: llvm_vc_target_os_type="NativeClient" ;;
*_vc_* -> *_cv_* ?

[krasin, 2011-08-08 21:25:13]

http://codereview.chromium.org/7484050/diff/1/autoconf/configure.ac
File autoconf/configure.ac (right):

http://codereview.chromium.org/7484050/diff/1/autoconf/configure.ac#newcode303
autoconf/configure.ac:303: llvm_vc_target_os_type="NativeClient" ;;
On 2011/08/08 20:36:46, jvoung wrote:
> *_vc_* -> *_cv_* ?
Thanks, good catch.

[sehr (please use chromium), 2011-08-10 22:16:53]

On 2011/08/08 21:25:13, krasin wrote:
> http://codereview.chromium.org/7484050/diff/1/autoconf/configure.ac
> File autoconf/configure.ac (right):
> 
> http://codereview.chromium.org/7484050/diff/1/autoconf/configure.ac#newcode303
> autoconf/configure.ac:303: llvm_vc_target_os_type="NativeClient" ;;
> On 2011/08/08 20:36:46, jvoung wrote:
> > *_vc_* -> *_cv_* ?
> Thanks, good catch.

LGTM.