All of lore.kernel.org
 help / color / mirror / Atom feed
* Possible incorrect linearization of code (master branch)
@ 2017-03-06 15:22 Dibyendu Majumdar
  2017-03-06 16:36 ` Luc Van Oostenryck
  0 siblings, 1 reply; 8+ messages in thread
From: Dibyendu Majumdar @ 2017-03-06 15:22 UTC (permalink / raw)
  To: Linux-Sparse

Hi,

I have this test program:

extern char *incr(char *p);
char *incr(char *p) {
 char *tmp = p;
 tmp += 5;
 return tmp;
}
int main(const char *argv[]) {
 char *text =  "abcde";
 char *p = incr(text);
 return (*p == 'e') ? 0 : 1;
}

The linearizer outputs following which I think is incorrect as it is
missing a load.

incr:
.L0:
        <entry-point>
        cast.64     %r3 <- (64) %arg1
        add.64      %r4 <- %r3, $5
        ptrcast.64  %r5 <- (64) %r4
        ret.64      %r5

main:
.L2:
        <entry-point>
        call.64     %r10 <- incr, "abcde"
        setne.32    %r15 <- %r13, $101
        ret.32      %r15

If I change the return in main to be a if else block then correct code
is generated.

int main(const char *argv[]) {
 char *text =  "abcde";
 char *p = incr(text);
 // return (*p == 'e') ? 0 : 1;
 if (*p == 'e')
  return 0;
 else
  return 1;
}

main:
.L2:
        <entry-point>
        call.64     %r10 <- incr, "abcde"
        load.8      %r12 <- 0[%r10]
        scast.32    %r13 <- (8) %r12
        setne.32    %r15 <- %r13, $101
        ret.32      %r15

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Possible incorrect linearization of code (master branch)
  2017-03-06 15:22 Possible incorrect linearization of code (master branch) Dibyendu Majumdar
@ 2017-03-06 16:36 ` Luc Van Oostenryck
  2017-03-06 18:47   ` Dibyendu Majumdar
  0 siblings, 1 reply; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-06 16:36 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: Linux-Sparse

On Mon, Mar 06, 2017 at 03:22:19PM +0000, Dibyendu Majumdar wrote:
> main:
> .L2:
>         <entry-point>
>         call.64     %r10 <- incr, "abcde"
>         setne.32    %r15 <- %r13, $101
>         ret.32      %r15


Hi,
This is already fixed in commit
	 https://git.kernel.org/cgit/devel/sparse/sparse.git/commit/?h=sparse-next-20170306&id=b8c268640114d614178d4875fbe0f5e6b53b036b 

Luc

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Possible incorrect linearization of code (master branch)
  2017-03-06 16:36 ` Luc Van Oostenryck
@ 2017-03-06 18:47   ` Dibyendu Majumdar
  2017-03-06 19:26     ` Luc Van Oostenryck
  0 siblings, 1 reply; 8+ messages in thread
From: Dibyendu Majumdar @ 2017-03-06 18:47 UTC (permalink / raw)
  To: Luc Van Oostenryck; +Cc: Linux-Sparse

On 6 March 2017 at 16:36, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> On Mon, Mar 06, 2017 at 03:22:19PM +0000, Dibyendu Majumdar wrote:
>> main:
>> .L2:
>>         <entry-point>
>>         call.64     %r10 <- incr, "abcde"
>>         setne.32    %r15 <- %r13, $101
>>         ret.32      %r15
>
>
> This is already fixed in commit
>          https://git.kernel.org/cgit/devel/sparse/sparse.git/commit/?h=sparse-next-20170306&id=b8c268640114d614178d4875fbe0f5e6b53b036b
>

Okay thanks. I had originally started from the release 0.5 version of
Sparse, and applied fixes selectively. Because I have a modified
version of Sparse with all global state removed, merging changes is a
bit painful as it has be done manually. That is why I have not been
tracking sparse-next as I thought it is not yet stable. I have now
merged all changes from master. Should I merge sparse-next now or wait
for it to be merged into master?

Regards
Dibyendu

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Possible incorrect linearization of code (master branch)
  2017-03-06 18:47   ` Dibyendu Majumdar
@ 2017-03-06 19:26     ` Luc Van Oostenryck
  2017-03-06 22:39       ` Dibyendu Majumdar
  0 siblings, 1 reply; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-06 19:26 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: Linux-Sparse

On Mon, Mar 6, 2017 at 7:47 PM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Okay thanks. I had originally started from the release 0.5 version of
> Sparse, and applied fixes selectively.

release 0.5 is quite old and a lot of patches have been added;
almost nothing related to correctness of LLVM but well about the correctness
of the linearization.

> Because I have a modified
> version of Sparse with all global state removed, merging changes is a
> bit painful as it has be done manually.

I can imagine this.
I, of course, hve no idea why you (have to) do this but I can only very strongly
advice you to try to avoid this as much as possible.

> That is why I have not been
> tracking sparse-next as I thought it is not yet stable. I have now
> merged all changes from master. Should I merge sparse-next now or wait
> for it to be merged into master?

It depends a bit you confortable you are with applying patches,
merging or rebasing
branches but as you have seen there is needed patches in sparse-next
that are not
yes in master although master was updated very recently.

It depends also about the nature of your changes, what is the
probability to have
nasty conflicts.

But idealy you would take very recent stuff but not too recent
(sparse-next itself may be
a bit too wild in the sense that the very top of it is often rebased).

-- Luc Van Oostenryck

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Possible incorrect linearization of code (master branch)
  2017-03-06 19:26     ` Luc Van Oostenryck
@ 2017-03-06 22:39       ` Dibyendu Majumdar
  2017-03-07  6:42         ` Luc Van Oostenryck
  2017-03-07 15:45         ` Christopher Li
  0 siblings, 2 replies; 8+ messages in thread
From: Dibyendu Majumdar @ 2017-03-06 22:39 UTC (permalink / raw)
  To: Luc Van Oostenryck; +Cc: Linux-Sparse

On 6 March 2017 at 19:26, Luc Van Oostenryck
<luc.vanoostenryck@gmail.com> wrote:
> On Mon, Mar 6, 2017 at 7:47 PM, Dibyendu Majumdar
>> Because I have a modified
>> version of Sparse with all global state removed, merging changes is a
>> bit painful as it has be done manually.
>
> I can imagine this.
> I, of course, hve no idea why you (have to) do this but I can only very strongly
> advice you to try to avoid this as much as possible.
>

As I mentioned before I am using Sparse to create a JIT compiler for
C. So this needs to be callable as a library - and I need the ability
to call it many times. Moreover it must be possible to call several
instances of Sparse simultaneously without conflict. To achieve all
this, all global state is held in a set of structures. The main change
is that the most function calls have an additional argument. The other
changes are related to initialization of the various global structures
used by Sparse. Generally I try to keep the code as far as possible
identical to Sparse except for these changes. Even so merging is very
painful.

Regards
Dibyendu

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Possible incorrect linearization of code (master branch)
  2017-03-06 22:39       ` Dibyendu Majumdar
@ 2017-03-07  6:42         ` Luc Van Oostenryck
  2017-03-07 15:45         ` Christopher Li
  1 sibling, 0 replies; 8+ messages in thread
From: Luc Van Oostenryck @ 2017-03-07  6:42 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: Linux-Sparse

On Mon, Mar 06, 2017 at 10:39:42PM +0000, Dibyendu Majumdar wrote:
> On 6 March 2017 at 19:26, Luc Van Oostenryck
> <luc.vanoostenryck@gmail.com> wrote:
> > On Mon, Mar 6, 2017 at 7:47 PM, Dibyendu Majumdar
> >> Because I have a modified
> >> version of Sparse with all global state removed, merging changes is a
> >> bit painful as it has be done manually.
> >
> > I can imagine this.
> > I, of course, hve no idea why you (have to) do this but I can only very strongly
> > advice you to try to avoid this as much as possible.
> >
> 
> As I mentioned before I am using Sparse to create a JIT compiler for
> C. So this needs to be callable as a library - and I need the ability
> to call it many times. Moreover it must be possible to call several
> instances of Sparse simultaneously without conflict. To achieve all
> this, all global state is held in a set of structures. The main change
> is that the most function calls have an additional argument. The other
> changes are related to initialization of the various global structures
> used by Sparse. Generally I try to keep the code as far as possible
> identical to Sparse except for these changes. Even so merging is very
> painful.

OK, I understand better now.
Yes, I imagine it must be painful.

Do you really need to have this ability to run several instances during
development, while investigating problems?

-- Luc 

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Possible incorrect linearization of code (master branch)
  2017-03-06 22:39       ` Dibyendu Majumdar
  2017-03-07  6:42         ` Luc Van Oostenryck
@ 2017-03-07 15:45         ` Christopher Li
  2017-03-07 17:13           ` Dibyendu Majumdar
  1 sibling, 1 reply; 8+ messages in thread
From: Christopher Li @ 2017-03-07 15:45 UTC (permalink / raw)
  To: Dibyendu Majumdar; +Cc: Luc Van Oostenryck, Linux-Sparse

On Tue, Mar 7, 2017 at 6:39 AM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:

> As I mentioned before I am using Sparse to create a JIT compiler for
> C. So this needs to be callable as a library - and I need the ability
> to call it many times. Moreover it must be possible to call several
> instances of Sparse simultaneously without conflict. To achieve all
> this, all global state is held in a set of structures. The main change
> is that the most function calls have an additional argument. The other

Adding an additional argument is a very big change.


> changes are related to initialization of the various global structures
> used by Sparse.

In your usage case, is it possible to use some kind of lock to avoid
racing to initialize sparse?

> Generally I try to keep the code as far as possible
> identical to Sparse except for these changes. Even so merging is very
> painful.

May be need a script of some short to automate part of the change.

Do you have that big and painful change already?

Chris

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: Possible incorrect linearization of code (master branch)
  2017-03-07 15:45         ` Christopher Li
@ 2017-03-07 17:13           ` Dibyendu Majumdar
  0 siblings, 0 replies; 8+ messages in thread
From: Dibyendu Majumdar @ 2017-03-07 17:13 UTC (permalink / raw)
  To: Christopher Li; +Cc: Luc Van Oostenryck, Linux-Sparse

Hi Chris,

On 7 March 2017 at 15:45, Christopher Li <sparse@chrisli.org> wrote:
> On Tue, Mar 7, 2017 at 6:39 AM, Dibyendu Majumdar
> <mobile@majumdar.org.uk> wrote:
>
>> As I mentioned before I am using Sparse to create a JIT compiler for
>> C. So this needs to be callable as a library - and I need the ability
>> to call it many times. Moreover it must be possible to call several
>> instances of Sparse simultaneously without conflict. To achieve all
>> this, all global state is held in a set of structures. The main change
>> is that the most function calls have an additional argument. The other
>
> Adding an additional argument is a very big change.
>

Indeed.

>
>> changes are related to initialization of the various global structures
>> used by Sparse.
>
> In your usage case, is it possible to use some kind of lock to avoid
> racing to initialize sparse?
>

It is not just the initialization - any execution of Sparse would have
to be restricted by locking.

>> Generally I try to keep the code as far as possible
>> identical to Sparse except for these changes. Even so merging is very
>> painful.
>
> May be need a script of some short to automate part of the change.
>
> Do you have that big and painful change already?
>

Yes, I also have some other changes to ensure that the code can be
compiled on Windows using Visual C++, plus I am using a CMake build
system. I have not converted all the code in Sparse - just the main
library, and the LLVM backend. I intend to add other backends in the
future as LLVM is too slow for a JIT engine.

You can see my project at https://github.com/dibyendumajumdar/dmr_c.

Regards
Dibyendu

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2017-03-07 17:40 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-03-06 15:22 Possible incorrect linearization of code (master branch) Dibyendu Majumdar
2017-03-06 16:36 ` Luc Van Oostenryck
2017-03-06 18:47   ` Dibyendu Majumdar
2017-03-06 19:26     ` Luc Van Oostenryck
2017-03-06 22:39       ` Dibyendu Majumdar
2017-03-07  6:42         ` Luc Van Oostenryck
2017-03-07 15:45         ` Christopher Li
2017-03-07 17:13           ` Dibyendu Majumdar

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.