similar to: [LLVMdev] instcombine Question

On Sep 13, 2012, at 2:23 PM, Chris Lattner <clattner at apple.com> wrote: > On Sep 13, 2012, at 12:00 PM, Mon Ping Wang <monping at apple.com> wrote: >>>> In C, integer to point conversions are implementation defined and >>>> depends on what the addressing structure of the execution environment >>>> is. Given the current definition of ptrtoint

On Sep 13, 2012, at 12:00 PM, Mon Ping Wang <monping at apple.com> wrote: >>> In C, integer to point conversions are implementation defined and >>> depends on what the addressing structure of the execution environment >>> is. Given the current definition of ptrtoint and intoptr, I feel that >>> the addressing structure feels like a flat memory model

On Sep 13, 2012, at 3:53 PM, Mon Ping Wang <monping at apple.com> wrote: >>> The problem with using ptrtoint and inttoptr is that one has to pick an intermediate integer type that is safe to convert to and from. Since the pointer size is target dependent, it seems unnatural to use ptrtoint and inttoptr for that. >> >> If we were to add first class support for this,

On Sep 13, 2012, at 7:51 AM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Mon Ping Wang [mailto:monping at apple.com] >> Sent: Thursday, September 13, 2012 1:55 AM >> To: Villmow, Micah >> Cc: llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between

> -----Original Message----- > From: Mon Ping Wang [mailto:monping at apple.com] > Sent: Thursday, September 13, 2012 1:55 AM > To: Villmow, Micah > Cc: llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between > address spaces > > > On Sep 12, 2012, at 2:45 PM, "Villmow, Micah" <Micah.Villmow at amd.com> >

> -----Original Message----- > From: Chris Lattner [mailto:clattner at apple.com] > Sent: Thursday, September 13, 2012 11:53 PM > To: Mon Ping Wang > Cc: Villmow, Micah; llvmdev at cs.uiuc.edu Mailing List > Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between > address spaces > > > On Sep 13, 2012, at 5:55 PM, Mon Ping Wang <monping at

On Sep 13, 2012, at 5:55 PM, Mon Ping Wang <monping at apple.com> wrote: >>> The pointer size is target dependent so it seems strange to choose an arbitrary size to convert to and from. Are you making a practical argument that 64b is sufficient on all machines so all targets can use that? In other words, pointers > 64 doesn't make any sense in terms of the address space? (A

Ping! > -----Original Message----- > From: Villmow, Micah > Sent: Tuesday, September 18, 2012 4:12 PM > To: 'Chris Lattner'; 'Mon Ping Wang' > Cc: 'llvm-commits at cs.uiuc.edu'; 'llvmdev at cs.uiuc.edu' > Subject: RE: [LLVMdev] Proposal: New IR instruction for casting between > address spaces > > Resending since I got an error. >

Hi, I am observing some incorrect behavior in basicaa, wherein two pointers that basicaa should determine to be MustAlias are ending up NoAlias - the other extreme :( I am blaming this on basicaa not handling inttoptr. Here is the relevant IR snippet. -------------------- %sunkaddr36 = ptrtoint %struct.BitParams* %bs to i32 %sunkaddr37 = add i32 %sunkaddr36, 16 %sunkaddr38 = inttoptr i32

> -----Original Message----- > From: Chris Lattner [mailto:clattner at apple.com] > Sent: Thursday, September 13, 2012 2:24 PM > To: Villmow, Micah > Cc: Mon Ping Wang; llvmdev at cs.uiuc.edu Mailing List > Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between > address spaces > > On Sep 13, 2012, at 12:00 PM, Mon Ping Wang <monping at apple.com>

On Sep 12, 2012, at 2:45 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > > >> -----Original Message----- >> From: Mon P Wang [mailto:monping at apple.com] >> Sent: Wednesday, September 12, 2012 1:12 PM >> To: Villmow, Micah >> Cc: Dan Gohman; llvmdev at cs.uiuc.edu >> Subject: Re: [LLVMdev] Proposal: New IR instruction for

If I don't bring in TargetData, then there is no way for me to verify the address space size in the verifier or in the auto-upgrade mechanisms. > -----Original Message----- > From: Eli Friedman [mailto:eli.friedman at gmail.com] > Sent: Thursday, September 20, 2012 2:32 PM > To: Villmow, Micah > Cc: Chris Lattner; Mon Ping Wang; llvm-commits at cs.uiuc.edu; > llvmdev at

We can't add a circular dependency between Target and VMCore. -Eli On Thu, Sep 20, 2012 at 8:21 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Ping! > >> -----Original Message----- >> From: Villmow, Micah >> Sent: Tuesday, September 18, 2012 4:12 PM >> To: 'Chris Lattner'; 'Mon Ping Wang' >> Cc: 'llvm-commits at

On Sep 13, 2012, at 4:55 PM, Chris Lattner <clattner at apple.com> wrote: > On Sep 13, 2012, at 3:53 PM, Mon Ping Wang <monping at apple.com> wrote: >>>> The problem with using ptrtoint and inttoptr is that one has to pick an intermediate integer type that is safe to convert to and from. Since the pointer size is target dependent, it seems unnatural to use ptrtoint and

On Thu, Sep 20, 2012 at 3:30 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > If I don't bring in TargetData, then there is no way for me to verify the address space size in the verifier or in the auto-upgrade mechanisms. And that's why I didn't like this approach in the first place. -Eli >> -----Original Message----- >> From: Eli Friedman

On Thu, 20 Sep 2012 15:34:52 -0700 Eli Friedman <eli.friedman at gmail.com> wrote: > On Thu, Sep 20, 2012 at 3:30 PM, Villmow, Micah > <Micah.Villmow at amd.com> wrote: > > If I don't bring in TargetData, then there is no way for me to > > verify the address space size in the verifier or in the > > auto-upgrade mechanisms. > > And that's why I

> -----Original Message----- > From: Mon P Wang [mailto:monping at apple.com] > Sent: Wednesday, September 12, 2012 1:12 PM > To: Villmow, Micah > Cc: Dan Gohman; llvmdev at cs.uiuc.edu > Subject: Re: [LLVMdev] Proposal: New IR instruction for casting between > address spaces > > Hi, > > On Sep 11, 2012, at 2:30 PM, Villmow, Micah wrote: > > > > >

Hello, I don't know very much about Macs, so may have missed some obvious steps, but I downloaded version 1.8.1 of RAqua.dmg and installed from the R package file. The Start R icon appeared in the applications directory, but crashed immediately on opening. Here is the log file: Date/Time: 2004-03-03 08:32:27 +1100 OS Version: 10.2.8 (Build 6R73) Host: Kylie-Kings-Computer.local.

On Mon, Mar 16, 2015 at 9:56 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > so just using pointer types instead of i64 will help common cases, but > will not address the general issue. Now part of this does some down to > using array parameters as a substitute for byval/direct parameters. As I > recall, this was done because it allowed a natural partial decomposition >

Hi. The patch I send before was too large so that it was dropped from the maling list. I'm sending again with smaller size. This patch set is the xen paravirtualization of hand written assenbly code. And I expect that much clean up is necessary before merge. We really need the feed back before starting actual clean up as Eddie already said before. Eddie discussed how to clean up and suggested