suggestion for Merging LLVM

suggestion for Merging LLVM

[Christopher Li]

Hi Pekka,

I already tag the sparse 0.4.4 release in git. Just waiting
for getting the release directory setup on kernel.org and it
is ready to go.

Now I am looking at your LLVM repository and the llvm patches.
I don't have a good sense for the later patch without looking at the
earlier changes.

I haven't done big repository merge before, this is the first one.
So I am looking for suggestion what is the best practice here.

Do we care about clean up the history and import the changes
step by step as patches or just a plain git merge of the LLVM
repository?

Thanks

Chris

Re: suggestion for Merging LLVM

[Jeff Garzik]

On 11/21/2011 09:43 PM, Christopher Li wrote:
> Hi Pekka,
>
> I already tag the sparse 0.4.4 release in git. Just waiting
> for getting the release directory setup on kernel.org and it
> is ready to go.
>
> Now I am looking at your LLVM repository and the llvm patches.
> I don't have a good sense for the later patch without looking at the
> earlier changes.
>
> I haven't done big repository merge before, this is the first one.
> So I am looking for suggestion what is the best practice here.
>
> Do we care about clean up the history and import the changes
> step by step as patches or just a plain git merge of the LLVM
> repository?

I don't see any reason to import step-by-step as patches.

Either merge it as a single "add incomplete LLVM backend" commit, 
dropping all pre-upstream history, or git merge.

FWIW I am sorta stuck; cannot figure out how to make 'phi' operation in 
LLVM work the way we need it to.  That is a crucial hurdle needed for 
loops.  LLVM fundamentally should be able to do it, but I'm not sure 
this works within the C API.  I was thinking my next step would be to 
whine on the llvm list.

A workaround is to resuscitate unssa() call, and all that entails.

	Jeff

Re: suggestion for Merging LLVM

[Pekka Enberg]

On 11/21/2011 09:43 PM, Christopher Li wrote:
> > I already tag the sparse 0.4.4 release in git. Just waiting
> > for getting the release directory setup on kernel.org and it
> > is ready to go.
> >
> > Now I am looking at your LLVM repository and the llvm patches.
> > I don't have a good sense for the later patch without looking at the
> > earlier changes.
> >
> > I haven't done big repository merge before, this is the first one.
> > So I am looking for suggestion what is the best practice here.
> >
> > Do we care about clean up the history and import the changes
> > step by step as patches or just a plain git merge of the LLVM
> > repository?

On Tue, 2011-11-22 at 00:52 -0500, Jeff Garzik wrote:
> I don't see any reason to import step-by-step as patches.
> 
> Either merge it as a single "add incomplete LLVM backend" commit, 
> dropping all pre-upstream history, or git merge.

Agreed.

I'd actually prefer that we keep the full history for one simple reason:
the commit changelogs. They provide valuable information on why we've
implemented the things the way we have.

> FWIW I am sorta stuck; cannot figure out how to make 'phi' operation in 
> LLVM work the way we need it to.  That is a crucial hurdle needed for 
> loops.  LLVM fundamentally should be able to do it, but I'm not sure 
> this works within the C API.  I was thinking my next step would be to 
> whine on the llvm list.
> 
> A workaround is to resuscitate unssa() call, and all that entails.

Did you check what kind of code http://llvm.org/demo/ generates for your
test case? I've noticed that LLVM is really picky sometime in what it
accepts as input. IIRC last time I looked at loops, there were some
significant differences in the asm we generate.

			Pekka

Re: suggestion for Merging LLVM

[Jeff Garzik]

On 11/22/2011 01:01 AM, Pekka Enberg wrote:
> On 11/21/2011 09:43 PM, Christopher Li wrote:
>> FWIW I am sorta stuck; cannot figure out how to make 'phi' operation in
>> LLVM work the way we need it to.  That is a crucial hurdle needed for
>> loops.  LLVM fundamentally should be able to do it, but I'm not sure
>> this works within the C API.  I was thinking my next step would be to
>> whine on the llvm list.
>>
>> A workaround is to resuscitate unssa() call, and all that entails.
>
> Did you check what kind of code http://llvm.org/demo/ generates for your
> test case? I've noticed that LLVM is really picky sometime in what it
> accepts as input. IIRC last time I looked at loops, there were some
> significant differences in the asm we generate.


The disassembler output is certainly sane and understandable.  Here's an 
example test case:

	extern int bar(int x);
	
	int foo (int x)
	{
	  int y = 0;
	  while (y < 1000) {
	    y += bar(x);
	  }
	
	  return y;
	}

The PHI operation in SSA being a union of control flows, we need to 
reference all input pseudos ... including pseudos generated by 
operations further down the in the code (i.e. pseudos not yet generated).

A classic forward reference is needed, and I cannot figure out how to do 
that in the LLVM C API, even though the forward reference is plain and 
obvious in the LLVM text disassembly.  My next step was going to trace 
through the front end to see how it generates forward refs, or be lazy 
and brain dump on an llvm mailing list somewhere.

Problems like this were the original motivation for my earlier LLVM 
backend to generate ASCII text.  I could work around this problem with 
an ugly string-based hack, if not using the C API... ;)

	Jeff

Re: suggestion for Merging LLVM

[Pekka Enberg]

On Tue, Nov 22, 2011 at 10:32 PM, Jeff Garzik <jeff@garzik.org> wrote:
> The disassembler output is certainly sane and understandable.  Here's an
> example test case:
>
>        extern int bar(int x);
>
>        int foo (int x)
>        {
>          int y = 0;
>          while (y < 1000) {
>            y += bar(x);
>          }
>
>          return y;
>        }
>
> The PHI operation in SSA being a union of control flows, we need to
> reference all input pseudos ... including pseudos generated by operations
> further down the in the code (i.e. pseudos not yet generated).
>
> A classic forward reference is needed, and I cannot figure out how to do
> that in the LLVM C API, even though the forward reference is plain and
> obvious in the LLVM text disassembly.  My next step was going to trace
> through the front end to see how it generates forward refs, or be lazy and
> brain dump on an llvm mailing list somewhere.

So pasting the above test program to http://llvm.org/demo/ and
switching to "LLVM C++ API code" target seems to suggest you're
interested in the LLVMReplaceAllUsesWith() API for forward references.

                                 Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for Merging LLVM

[Jeff Garzik]

On 11/22/2011 03:38 PM, Pekka Enberg wrote:
> So pasting the above test program tohttp://llvm.org/demo/  and
> switching to "LLVM C++ API code" target seems to suggest you're
> interested in the LLVMReplaceAllUsesWith() API for forward references.

Cute trick, outputting C++ API code.  I think LLVMReplaceAllUsesWith() 
may indeed be precisely what I needed.

Thanks,

	Jeff

Re: suggestion for Merging LLVM

[Jeff Garzik]

On 11/22/2011 03:38 PM, Pekka Enberg wrote:
> So pasting the above test program tohttp://llvm.org/demo/  and
> switching to "LLVM C++ API code" target seems to suggest you're
> interested in the LLVMReplaceAllUsesWith() API for forward references.

Sent pull req via github.

List implementation is cheesy (inefficient if list ever gets woefully 
large) singly-linked list, but it is pretty simple.  Turned out that 
postponing LLVMAddIncoming() call works better than 
LLVMReplaceAllUsesWith() API:


(warning: do not apply directly, patch is unfortunately word-wrapped; 
see pull request)

--- a/sparse-llvm.c
+++ b/sparse-llvm.c
@@ -17,11 +17,21 @@
  #include "linearize.h"
  #include "flow.h"

+struct phi_fwd {
+       struct phi_fwd                  *next;
+
+       LLVMValueRef                    phi;
+       pseudo_t                        pseudo;
+       bool                            resolved;
+};
+
  struct function {
         LLVMBuilderRef                  builder;
         LLVMTypeRef                     type;
         LLVMValueRef                    fn;
         LLVMModuleRef                   module;
+
+       struct phi_fwd                  *fwd_list;
  };

  static inline bool symbol_is_fp_type(struct symbol *sym)
@@ -794,6 +804,67 @@ static void output_op_call(struct function *fn, 
struct instruction *insn)
         insn->target->priv = target;
  }

+static void store_phi_fwd(struct function *fn, LLVMValueRef phi,
+                         pseudo_t pseudo)
+{
+       struct phi_fwd *fwd;
+
+       fwd = calloc(1, sizeof(*fwd));
+       fwd->phi = phi;
+       fwd->pseudo = pseudo;
+
+       /* append fwd ref to function-wide list */
+       if (!fn->fwd_list)
+               fn->fwd_list = fwd;
+       else {
+               struct phi_fwd *last = fn->fwd_list;
+
+               while (last->next)
+                       last = last->next;
+               last->next = fwd;
+       }
+}
+
+static void output_phi_fwd(struct function *fn, pseudo_t pseudo, 
LLVMValueRef v)
+{
+       struct phi_fwd *fwd = fn->fwd_list;
+
+       while (fwd) {
+               struct phi_fwd *tmp;
+
+               tmp = fwd;
+               fwd = fwd->next;
+
+               if (tmp->pseudo == pseudo && !tmp->resolved) {
+                       LLVMValueRef phi_vals[1];
+                       LLVMBasicBlockRef phi_blks[1];
+
+                       phi_vals[0] = v;
+                       phi_blks[0] = pseudo->def->bb->priv;
+
+                       LLVMAddIncoming(tmp->phi, phi_vals, phi_blks, 1);
+
+                       tmp->resolved = true;
+               }
+       }
+}
+
+static void output_op_phisrc(struct function *fn, struct instruction *insn)
+{
+       LLVMValueRef v;
+
+       assert(insn->target->priv == NULL);
+
+       /* target = src */
+       v = pseudo_to_value(fn, insn, insn->phi_src);
+       insn->target->priv = v;
+
+       assert(insn->target->priv != NULL);
+
+       /* resolve forward references to this phi source, if present */
+       output_phi_fwd(fn, insn->target, v);
+}
+
  static void output_op_phi(struct function *fn, struct instruction *insn)
  {
         pseudo_t phi;
@@ -803,7 +874,7 @@ static void output_op_phi(struct function *fn, 
struct instruction *insn)
                                 "phi");
         int pll = 0;
         FOR_EACH_PTR(insn->phi_list, phi) {
-               if (pseudo_to_value(fn, insn, phi))     /* skip VOID */
+               if (pseudo_to_value(fn, insn, phi))     /* skip VOID, 
fwd refs*/
                         pll++;
         } END_FOR_EACH_PTR(phi);

@@ -815,11 +886,13 @@ static void output_op_phi(struct function *fn, 
struct instruction *insn)
                 LLVMValueRef v;

                 v = pseudo_to_value(fn, insn, phi);
-               if (v) {                        /* skip VOID */
+               if (v) {                        /* skip VOID, fwd refs */
                         phi_vals[idx] = v;
                         phi_blks[idx] = phi->def->bb->priv;
                         idx++;
                 }
+               else if (phi->type == PSEUDO_PHI)       /* fwd ref */
+                       store_phi_fwd(fn, target, phi);
         } END_FOR_EACH_PTR(phi);

         LLVMAddIncoming(target, phi_vals, phi_blks, pll);
@@ -916,8 +989,7 @@ static void output_insn(struct function *fn, struct 
instruction *insn)
                 assert(0);
                 break;
         case OP_PHISOURCE:
-               /* target = src */
-               insn->target->priv = pseudo_to_value(fn, insn, 
insn->phi_src);
+               output_op_phisrc(fn, insn);
                 break;
         case OP_PHI:
                 output_op_phi(fn, insn);
@@ -1026,7 +1098,7 @@ static void output_fn(LLVMModuleRef module, struct 
entrypoint *ep)
         struct symbol *ret_type = sym->ctype.base_type->ctype.base_type;
         LLVMTypeRef arg_types[MAX_ARGS];
         LLVMTypeRef return_type;
-       struct function function;
+       struct function function = { .module = module };
         struct basic_block *bb;
         struct symbol *arg;
         const char *name;
@@ -1043,8 +1115,6 @@ static void output_fn(LLVMModuleRef module, struct 
entrypoint *ep)

         return_type = symbol_type(module, ret_type);

-       function.module = module;

Re: suggestion for Merging LLVM

[Pekka Enberg]

On Wed, Nov 23, 2011 at 8:01 AM, Jeff Garzik <jeff@garzik.org> wrote:
> On 11/22/2011 03:38 PM, Pekka Enberg wrote:
>>
>> So pasting the above test program tohttp://llvm.org/demo/  and
>> switching to "LLVM C++ API code" target seems to suggest you're
>> interested in the LLVMReplaceAllUsesWith() API for forward references.
>
> Sent pull req via github.
>
> List implementation is cheesy (inefficient if list ever gets woefully large)
> singly-linked list, but it is pretty simple.  Turned out that postponing
> LLVMAddIncoming() call works better than LLVMReplaceAllUsesWith() API:
>
>
> (warning: do not apply directly, patch is unfortunately word-wrapped; see
> pull request)

Pulled, thanks!

P.S. Could you please put your test cases under validation/backend?
It's really easy to make them part of regular "make check".
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for Merging LLVM

[Christopher Li]

On Mon, Nov 21, 2011 at 10:01 PM, Pekka Enberg <penberg@kernel.org> wrote:
> Agreed.
>
> I'd actually prefer that we keep the full history for one simple reason:
> the commit changelogs. They provide valuable information on why we've
> implemented the things the way we have.

OK， I will just do the git merge then. Can you generate a pull request?

I just check out the sparse-llvm, the tip of the tree is broken for me:

     CC       sparse-llvm.o
sparse-llvm.c: In function ‘sym_struct_type’:
sparse-llvm.c:117:2: warning: implicit declaration of function
‘LLVMStructCreateNamed’ [-Wimplicit-function-declaration]
sparse-llvm.c:117:6: warning: assignment makes pointer from integer
without a cast [enabled by default]
sparse-llvm.c:129:2: warning: implicit declaration of function
‘LLVMStructSetBody’ [-Wimplicit-function-declaration]
     LINK     sparse-llvm
sparse-llvm.o: In function `sym_struct_type':
/export/git/sparse-llvm/sparse-llvm.c:117: undefined reference to
`LLVMStructCreateNamed'
/export/git/sparse-llvm/sparse-llvm.c:129: undefined reference to
`LLVMStructSetBody'
collect2: ld returned 1 exit status

I am using llvm 2.9, I guess my llvm is too new?

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for Merging LLVM

[Jeff Garzik]

On 11/24/2011 08:45 PM, Christopher Li wrote:
> I am using llvm 2.9, I guess my llvm is too new?

I would guess too-old.  I use a git checkout from the LLVM repo.

	Jeff

Re: suggestion for Merging LLVM

[Pekka Enberg]

> On 11/24/2011 08:45 PM, Christopher Li wrote:
> > I am using llvm 2.9, I guess my llvm is too new?

On Thu, 2011-11-24 at 21:25 -0500, Jeff Garzik wrote:
> I would guess too-old.  I use a git checkout from the LLVM repo.

We require LLVM 3.0 which hasn't been released because of this API:

https://github.com/penberg/sparse-llvm/commit/ea97bb4c5221a9be275b2d93dc90354bd6081a8c

			Pekka

Re: suggestion for Merging LLVM

[Christopher Li]

On Thu, Nov 24, 2011 at 9:52 PM, Pekka Enberg <penberg@kernel.org> wrote:
>> On 11/24/2011 08:45 PM, Christopher Li wrote:
>> > I am using llvm 2.9, I guess my llvm is too new?
>
> On Thu, 2011-11-24 at 21:25 -0500, Jeff Garzik wrote:
>> I would guess too-old.  I use a git checkout from the LLVM repo.
>
> We require LLVM 3.0 which hasn't been released because of this API:

Hmm, how does older version of LLVM deal with structure refering themself?

I hope there is a way so I can at least have an option to use the
released version of LLVM.  I don't mind using LLVM 3.0 if it is there,
but requiring unreleased version of LLVM seems too bleeding edge.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for Merging LLVM

[Pekka Enberg]

On Thu, Nov 24, 2011 at 9:52 PM, Pekka Enberg <penberg@kernel.org> wrote:
>>> On 11/24/2011 08:45 PM, Christopher Li wrote:
>>> > I am using llvm 2.9, I guess my llvm is too new?
>>
>> On Thu, 2011-11-24 at 21:25 -0500, Jeff Garzik wrote:
>>> I would guess too-old.  I use a git checkout from the LLVM repo.
>>
>> We require LLVM 3.0 which hasn't been released because of this API:

On Fri, Nov 25, 2011 at 8:28 AM, Christopher Li <sparse@chrisli.org> wrote:
> Hmm, how does older version of LLVM deal with structure refering themself?
>
> I hope there is a way so I can at least have an option to use the
> released version of LLVM.  I don't mind using LLVM 3.0 if it is there,
> but requiring unreleased version of LLVM seems too bleeding edge.

I wasn't able to find out any C API for that and assume it was only
possible with the C++ API. That said, I'd also be happy to use
something else to be compatible with older versions if there is one.
Any LLVM experts on the list?

LLVM 3.0 is going to be released "real soon now" so I don't think it's
a problem in practice. We'd need to add a version check, though so we
don't break build on machines that have older LLVM installed.

                                 Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for Merging LLVM

[Christopher Li]

On Thu, Nov 24, 2011 at 10:43 PM, Pekka Enberg <penberg@kernel.org> wrote:
> I wasn't able to find out any C API for that and assume it was only
> possible with the C++ API. That said, I'd also be happy to use
> something else to be compatible with older versions if there is one.
> Any LLVM experts on the list?

If it just need to use the C++ API, we can compile a bridge c++ file
to export the missing C++ API to C file. It is actually pretty common praticse
if you play with LLVM internal a lot, some API just don't exist in C yet.
We are already using g++ to link llvm, one more c++ file could not hurt.
If we need some C++ only API later, we can add it there as well.

What do you say?

> LLVM 3.0 is going to be released "real soon now" so I don't think it's
> a problem in practice. We'd need to add a version check, though so we
> don't break build on machines that have older LLVM installed.

Still, it will take a while for the distribution to update to the new version.

Chris

Re: suggestion for Merging LLVM

[Pekka Enberg]

Hi Chris,

On Thu, Nov 24, 2011 at 10:43 PM, Pekka Enberg <penberg@kernel.org> wrote:
>> I wasn't able to find out any C API for that and assume it was only
>> possible with the C++ API. That said, I'd also be happy to use
>> something else to be compatible with older versions if there is one.
>> Any LLVM experts on the list?

On Fri, Nov 25, 2011 at 10:05 AM, Christopher Li <sparse@chrisli.org> wrote:
> If it just need to use the C++ API, we can compile a bridge c++ file
> to export the missing C++ API to C file. It is actually pretty common praticse
> if you play with LLVM internal a lot, some API just don't exist in C yet.
> We are already using g++ to link llvm, one more c++ file could not hurt.
> If we need some C++ only API later, we can add it there as well.
>
> What do you say?

Well, sure, that would be the perfect solution.

Unfortunately, I'm not at all familiar with the C++ API. I did look at
just adding the LLVM 3.0 LLVMStructCreateNamed() and
LLVMStructSetBody() wrappers on top of LLVM 2.8 but they don't compile
because StructType API changed. So it's not going to be as simple as
copy-pasting the missing functions to sparse.git.

On Thu, Nov 24, 2011 at 10:43 PM, Pekka Enberg <penberg@kernel.org> wrote:
>> LLVM 3.0 is going to be released "real soon now" so I don't think it's
>> a problem in practice. We'd need to add a version check, though so we
>> don't break build on machines that have older LLVM installed.

On Fri, Nov 25, 2011 at 10:05 AM, Christopher Li <sparse@chrisli.org> wrote:
> Still, it will take a while for the distribution to update to the new version.

Sure.

Do you consider this to be a merge blocker? I'd personally just go
forward with LLVM 3.0 and add the compat wrappers along the way if
there are people who actually care about it.

                                Pekka

Re: suggestion for Merging LLVM

[Jeff Garzik]

On 11/25/2011 03:05 AM, Christopher Li wrote:
> On Thu, Nov 24, 2011 at 10:43 PM, Pekka Enberg<penberg@kernel.org>  wrote:
>> I wasn't able to find out any C API for that and assume it was only
>> possible with the C++ API. That said, I'd also be happy to use
>> something else to be compatible with older versions if there is one.
>> Any LLVM experts on the list?
>
> If it just need to use the C++ API, we can compile a bridge c++ file
> to export the missing C++ API to C file. It is actually pretty common praticse
> if you play with LLVM internal a lot, some API just don't exist in C yet.
> We are already using g++ to link llvm, one more c++ file could not hurt.
> If we need some C++ only API later, we can add it there as well.
>
> What do you say?
>
>> LLVM 3.0 is going to be released "real soon now" so I don't think it's
>> a problem in practice. We'd need to add a version check, though so we
>> don't break build on machines that have older LLVM installed.
>
> Still, it will take a while for the distribution to update to the new version.

Pulling in bits of LLVM itself into sparse, to make older versions work, 
seems like a mess of work and maintenance without a driving need.   Just 
note that 3.0 is required, and things will sort themselves out in time.

	Jeff

Re: suggestion for Merging LLVM

[Christopher Li]

On Fri, Nov 25, 2011 at 9:52 AM, Jeff Garzik <jeff@garzik.org> wrote:
>
> Pulling in bits of LLVM itself into sparse, to make older versions work,
> seems like a mess of work and maintenance without a driving need.   Just
> note that 3.0 is required, and things will sort themselves out in time.

I hate big mess too. However I have a strong motivation to support the
released version of LLVM (if it does make a big mess in the process).

I am not asking to back port the LLVM 3.0 code to the 2.x series.
That is wrong.  If 2.x does not have not provide this features, I am fine
with not supporting 2.x LLVM and require 3.0 only.

However if it is just C vs C++ API, I don't mind accessing the C++ API in 2.x.
I believe we need to have a mechanism to use the LLVM C++ API any way.
The LLVM C API is only a subset of the C++ API. I draw the line at
accessing the API vs backing the LLVM code.

In the long way, sparse will have to deal with different version of
LLVM any way.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for Merging LLVM

[Jeff Garzik]

On 11/25/2011 02:13 PM, Christopher Li wrote:
> On Fri, Nov 25, 2011 at 9:52 AM, Jeff Garzik<jeff@garzik.org>  wrote:
>>
>> Pulling in bits of LLVM itself into sparse, to make older versions work,
>> seems like a mess of work and maintenance without a driving need.   Just
>> note that 3.0 is required, and things will sort themselves out in time.
>
> I hate big mess too. However I have a strong motivation to support the
> released version of LLVM (if it does make a big mess in the process).
>
> I am not asking to back port the LLVM 3.0 code to the 2.x series.
> That is wrong.  If 2.x does not have not provide this features, I am fine
> with not supporting 2.x LLVM and require 3.0 only.
>
> However if it is just C vs C++ API, I don't mind accessing the C++ API in 2.x.
> I believe we need to have a mechanism to use the LLVM C++ API any way.
> The LLVM C API is only a subset of the C++ API. I draw the line at
> accessing the API vs backing the LLVM code.

According to http://llvm.org/ the release date for 3.0 is November 30, 
downgrading due to impatience.  If Pekka wants to get it going on 2.x 
I've no objection, but I am lazy and see no reason to do any extra work 
with 3.0 release so close.

	Jeff

Re: suggestion for Merging LLVM

[Christopher Li]

On Fri, Nov 25, 2011 at 12:18 PM, Jeff Garzik <jeff@garzik.org> wrote:
>
> According to http://llvm.org/ the release date for 3.0 is November 30,
> downgrading due to impatience.  If Pekka wants to get it going on 2.x I've
> no objection, but I am lazy and see no reason to do any extra work with 3.0
> release so close.
>

I will take a look how hard it is hard to support llvm 2.9. Don't know when the
3.0 will be available in Fedora.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: suggestion for Merging LLVM

[Pekka Enberg]

On Fri, Nov 25, 2011 at 12:18 PM, Jeff Garzik <jeff@garzik.org> wrote:
> > According to http://llvm.org/ the release date for 3.0 is November 30,
> > downgrading due to impatience.  If Pekka wants to get it going on 2.x I've
> > no objection, but I am lazy and see no reason to do any extra work with 3.0
> > release so close.

On Fri, 2011-11-25 at 12:30 -0800, Christopher Li wrote:
> I will take a look how hard it is hard to support llvm 2.9. Don't know when the
> 3.0 will be available in Fedora.

Ping? LLVM 3.0 is out now officially.

Re: suggestion for Merging LLVM

[Christopher Li]

On Tue, Dec 13, 2011 at 12:29 PM, Pekka Enberg <penberg@kernel.org> wrote:
>
> Ping? LLVM 3.0 is out now officially.


Glad to heard that LLVM 3.0 is out. I haven't able to make the llvm
2.x work yet.
I am fine with LLVM 3.0 for now.

I have one question regarding this change:
2ded1e7406914eda77abde035416140849d76f68

    sparse: Bump up sizeof(_Bool) to 8 bits

    We need sizeof(_Bool) to be one byte to generate code for boolean
expressions
    in the LLVM backend.

Sparse already evaluate sizeof(_Bool) as 8 bits. It current just give warnings.
Will remove the warning sufficient to make sparse-llvm happy?
I take a look at the code LLVM generate, It seem LLVM treat _Bool as 1
bit integer
as well. Can we not change the internal representation of _Bool, only
the sizeof(_Bool)?

Thanks

Chris

Re: suggestion for Merging LLVM

[Pekka Enberg]

On Thu, Dec 15, 2011 at 11:34 PM, Christopher Li <sparse@chrisli.org> wrote:
> I have one question regarding this change:
> 2ded1e7406914eda77abde035416140849d76f68
>
>    sparse: Bump up sizeof(_Bool) to 8 bits
>
>    We need sizeof(_Bool) to be one byte to generate code for boolean
> expressions
>    in the LLVM backend.
>
> Sparse already evaluate sizeof(_Bool) as 8 bits. It current just give warnings.
> Will remove the warning sufficient to make sparse-llvm happy?
> I take a look at the code LLVM generate, It seem LLVM treat _Bool as 1
> bit integer
> as well. Can we not change the internal representation of _Bool, only
> the sizeof(_Bool)?

No, it's not sufficient right now. For something like this:

#include <stdbool.h>

bool is_zero(int x)
{
	return !x;
}

you'd get:

[penberg@tux sparse]$ ./sparse-llvm bool.c
bool.c:3:6: warning: symbol 'is_zero' was not declared. Should it be static?
invalid bit size 1 for type 2

if you revert the commit. However, LLVM 3.0 seems to support 1 bit
integer types so we can probably clean that up.

                                Pekka
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html