search for: junbums

----- Original Message ----- > From: "Evan Cheng" <evan.cheng at apple.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> > Sent: Wednesday, November 20, 2013 7:48:13 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > > > On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > > > ----- Original Message ----- > >> From: &q...

----- Original Message ----- > From: "Evan Cheng" <evan.cheng at apple.com> > To: "Junbum Lim" <junbums at gmail.com> > Cc: llvmdev at cs.uiuc.edu > Sent: Wednesday, November 20, 2013 7:01:49 PM > Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare > > > On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com> wrote: > > > > > >...

...l Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Evan Cheng" <evan.cheng at apple.com> >> To: "Hal Finkel" <hfinkel at anl.gov> >> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >> Sent: Wednesday, November 20, 2013 7:48:13 PM >> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >> >> >> On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: >> >>> ----- Original Message -...

...at anl.gov> wrote: > >> ----- Original Message ----- >>> From: "Evan Cheng" <evan.cheng at apple.com> >>> To: "Hal Finkel" <hfinkel at anl.gov> >>> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >>> Sent: Wednesday, November 20, 2013 7:48:13 PM >>> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >>> >>> >>> On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: >>> >>>&...

On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Evan Cheng" <evan.cheng at apple.com> >> To: "Junbum Lim" <junbums at gmail.com> >> Cc: llvmdev at cs.uiuc.edu >> Sent: Wednesday, November 20, 2013 7:01:49 PM >> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >> >> >> On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com> wrote: >>...

...to sink a GEP without converting it into a set of integer operations (ptrtoint/add/inttoptr) if the address mode is derived only from a single GEP. Thanks, Jun On Nov 12, 2013, at 7:14 PM, Evan Cheng <evan.cheng at apple.com> wrote: > > On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com> wrote: > >> >> I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. > > I believe it's primary for address mode matching where only par...

On Nov 20, 2013, at 3:10 PM, Junbum Lim <junbums at gmail.com> wrote: > > > When multiple GEPs or other operations are used for the address calculation, OptimizeMemoryInst() performs address matching and determines a final addressing expression as a simple form (e.g., ptrtoint/add/inttoptr) and sinks it into user's block so tha...

...: >> >>> ----- Original Message ----- >>>> From: "Evan Cheng" <evan.cheng at apple.com> >>>> To: "Hal Finkel" <hfinkel at anl.gov> >>>> Cc: "LLVM" <llvmdev at cs.uiuc.edu>, "Junbum Lim" <junbums at gmail.com> >>>> Sent: Wednesday, November 20, 2013 7:48:13 PM >>>> Subject: Re: [LLVMdev] sinking address computing in CodeGenPrepare >>>> >>>> >>>> On Nov 20, 2013, at 5:38 PM, Hal Finkel <hfinkel at anl.gov> wrote: >&gt...

...an.cheng at apple.com> wrote: > The reason for this is to allow folding of address computation into loads and stores. A lot of modern arch, e.g. X86 and arm, have complex addressing mode. > > Evan > > Sent from my iPad > >> On Nov 12, 2013, at 8:39 AM, Junbum Lim <junbums at gmail.com> wrote: >> >> Hi All, >> >> In CodeGenPrepare pass, OptimizeMemoryInst() try to sink address computing into users' block by converting GET to integers? It appear that it have impacts on ISel's result, but I'm not clear about the main purpose o...

On Nov 12, 2013, at 11:24 AM, Junbum Lim <junbums at gmail.com> wrote: > > I wonder why CodeGenPrepare breaks GEP into integer calculations (ptrtoin/add/inttopt) instead of directly sinking the address calculation using GEP into user's block. I believe it's primary for address mode matching where only part of the GEP can be fol...

Hi, I have a question about the definitions of t2LDRSB and t2LDRSB_PRE in ARMInstrThumb2.td : I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced?

The reason for this is to allow folding of address computation into loads and stores. A lot of modern arch, e.g. X86 and arm, have complex addressing mode. Evan Sent from my iPad > On Nov 12, 2013, at 8:39 AM, Junbum Lim <junbums at gmail.com> wrote: > > Hi All, > > In CodeGenPrepare pass, OptimizeMemoryInst() try to sink address computing into users' block by converting GET to integers? It appear that it have impacts on ISel's result, but I'm not clear about the main purpose of the transforma...

Hi Junbum, > I was aware that the definitions of target RegisterClass (outs) are different in t2LDRSB and t2LDRSB_PRE. While t2LDRSB uses rGPR, t2LDRSB_PRE uses GPR. I wonder if lr and pc are already prevented from being allocated in pre-indexing case, because of some register hint that is being enforced? They're not allocated during CodeGen because of the Reserved.set(…) calls in

Hi All, In CodeGenPrepare pass, OptimizeMemoryInst() try to sink address computing into users' block by converting GET to integers? It appear that it have impacts on ISel's result, but I'm not clear about the main purpose of the transformation. FROM : for.body.lr.ph: %zzz = getelementptr inbounds %struct.SS* %a2, i32 0, i32 35 for.body: %4 =

Thank you for the answer. What is the main reason of allowing this inconsistency in the td file? I guess that's because of the "some" distinction between the writeback and non-writeback versions. Is there any benefit from the inconsistency by using GRP in .td file and freezing lr and pc during register allocation in writeback version? Thanks, Junbum On May 23, 2013, at 11:51 AM,

Hi all, I have searched for a long time to find out R program about V ariable S election for GLMM (Generalized Linear Mixed Model). I saw several great R packages for V ariable S election. I  also found several R packages for GLMM. But, I did not find yet R package about V ariable S election for GLMM even though sevel  papers about it have been published.   In fact,  I need V ariable