search for: hatanaka

I propose that we make Akira Hatanaka the code owner for the Mips code generator. He has worked on the Mips code generator for four years now and done high quality work that whole time. He is the key person inside of Mips for reviewing patches and giving advice to other developers regarding new Mips work. To assure the future qua...

...hese builtins. You are expecting them > to behave as if they were the standard library calls. They are not > equivalent and the naming similarity is an unfortunate historical artifact. > Use the standard library functions instead. > > -Jim > > On Apr 27, 2011, at 1:22 PM, Akira Hatanaka wrote: > > > I declared gi2 as "volatile" and I think gi2 is still incremented once. > > Here is a snippet of the code. Line 39 - 42 increments gi2. > > > > According to the standard, shouldn't ++gi2 be executed twice regardless > of whether gi2 is volati...

...exception > handling. Any other use, including any direct calls of the builtins in user > code, are a bad idea with no guaranteed behaviour. That they're exposed at > all is, again, for historical purposes. Don't use them. > > -Jim > > On Apr 27, 2011, at 3:45 PM, Akira Hatanaka wrote: > > > Okay. I understand builtin functions do not have to behave exactly the > same way as standard library functions. What I wanted to know is what should > the code generated by llvm (clang + llc) look like (I am working on the Mips > back-end now). I guess there should b...

...iler use in the context of SjLj exception handling. Any other use, including any direct calls of the builtins in user code, are a bad idea with no guaranteed behaviour. That they're exposed at all is, again, for historical purposes. Don't use them. -Jim On Apr 27, 2011, at 3:45 PM, Akira Hatanaka wrote: > Okay. I understand builtin functions do not have to behave exactly the same way as standard library functions. What I wanted to know is what should the code generated by llvm (clang + llc) look like (I am working on the Mips back-end now). I guess there should be a behavior users expec...

...)? # line 39 - 47 ldr r1, LCPI1_1 ldr r2, [r1] add r2, r2, #1 str r2, [r1] add r4, pc, #8 @ eh_setjmp begin str r4, [r0, #4] mov r0, #0 add pc, pc, #0 mov r0, #1 @ eh_setjmp end ... LCPI1_1: .long _gi2 .align 2 On Wed, Apr 27, 2011 at 11:38 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > I have another basic question about setjmp/longjmp. > > When I compile and run the following program, is it expected that global > variable gi2 will be incremented twice? It seems that the code generated > with clang and llc increments it only...

----- Original Message ----- > From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> > To: "Akira Hatanaka" <ahatanak at gmail.com> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> > Sent: Tuesday, March 26, 2013 12:40:44 PM > Subject: Re: [LLVMdev] [PATCH] RegScavenger::scavengeRegister > > >...

...is no C standard to follow for these builtins. You are expecting them to behave as if they were the standard library calls. They are not equivalent and the naming similarity is an unfortunate historical artifact. Use the standard library functions instead. -Jim On Apr 27, 2011, at 1:22 PM, Akira Hatanaka wrote: > I declared gi2 as "volatile" and I think gi2 is still incremented once. > Here is a snippet of the code. Line 39 - 42 increments gi2. > > According to the standard, shouldn't ++gi2 be executed twice regardless of whether gi2 is volatile or not? Isn't the mi...

On Apr 6, 2013, at 12:42 AM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- >> From: "Jakob Stoklund Olesen" <stoklund at 2pi.dk> >> To: "Akira Hatanaka" <ahatanak at gmail.com> >> Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu>, "Hal Finkel" <hfinkel at anl.gov> >> Sent: Tuesday, March 26, 2013 12:40:44 PM >> Subject: Re: [LLVMdev] [PATCH] RegScavenger::scavengeRegister >&...

On 09/24/2015 01:47 PM, Akira Hatanaka wrote: > On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > > On 09/23/2015 08:48 AM, Akira Hatanaka wrote: >> On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames >> &l...

I have a question about MCExpr and its subclasses defined in MCExpr.h. I am trying to get Mips' direct object emission working. Line 283 of MCElfStreamer.cpp reads like this: 00283 case MCExpr::Target: llvm_unreachable("Can't handle target exprs yet!"); Does this mean that if I use a subclass of MCTargetExpr to lower MachineOperands to MCOperands, it won't work?

This is the email I sent last week. ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Wed, May 8, 2013 at 7:04 PM Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clearing mem operands. To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> The following code snippet taken from StackColoring::remapInstructions clears a me...

The following code snippet taken from StackColoring::remapInstructions clears a mem operand if it can't guarantee whether the memoperand's underlying value aliases with the merged allocas: // Update the MachineMemOperand to use the new alloca. 522 for (MachineInstr::mmo_iterator MM = I->memoperands_begin(), .... // Climb up and find the original alloca. 532 V =

The patch LGTM. The StackColoring patch is still too conservative and I am consulting with Jakob and Andy about possible solutions. On May 13, 2013, at 10:33 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This is the email I sent last week. > > ---------- Forwarded message ---------- > From: Akira Hatanaka <ahatanak at gmail.com> > Date: Wed, May 8, 2013 at 7:04 PM > Subject: [PATCH] Minor fix to StackColoring to avoid needlessly clear...

On 09/24/2015 03:04 PM, Akira Hatanaka wrote: > On Thu, Sep 24, 2015 at 1:53 PM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > > > On 09/24/2015 01:47 PM, Akira Hatanaka wrote: >> On Wed, Sep 23, 2015 at 11:13 AM, Philip Reames >> &l...

On Apr 13, 2011, at 9:51 AM, Akira Hatanaka wrote: > int > main (int argc, char** argv) > { > int n = atoi(argv[1]), r; > > if ((r = setjmp (buf))) > { > printf("n = %d\n", n); > return 0; > } Non-volatile local variables are not preserved by setjmp(), so this program can pri...

On 09/23/2015 08:48 AM, Akira Hatanaka wrote: > On Tue, Sep 22, 2015 at 8:31 AM, Philip Reames > <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote: > > To be clear, this is a debuging aid only? It's not something > required for correctness? I'm somewhat bothered by t...

On Mar 25, 2013, at 12:04 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > This patch adds parameter "EliminateFI" to RegScavenger::scavengeRegister, which tells register scavenger not to eliminate frame index of the emergency spill slot if set to false. > > I have pseudo load, store and copy instructions which a...

Please see the attached patch. There was one more line which was calling isInsideBundle without any check. On Thu, Oct 25, 2012 at 7:08 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Oct 25, 2012, at 7:01 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > Is it safe or legal to call isInsideBundle even when I == E? > > > No, neither. > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121025/d11c04f2/att...

...t method for expressions (or not). Often, the generic printing is sufficient, but not always. You can register a custom operand print method on complex operands via the "PrintMethod" attribute. ARM makes heavy use of this for all manner of things. -Jim On Oct 17, 2011, at 6:02 PM, Akira Hatanaka wrote: > I guess that means I should be calling MCSymbolRefExpr::Create, like > ARM does, when I lower symbol operands. Is that right? > > If MCSymbolRefExpr objects should be created, am I supposed to add > code to MCExpr::print (MCExpr.cpp:37) in order to print symbol > operan...

On Mon, Mar 25, 2013 at 4:02 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > > On Mar 25, 2013, at 2:51 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > Yes, it sounds like it will solve the problem. > > > > Using the following example where live ranges of accumulators $vreg_acc0 > and $vreg_acc1 conflict, > > > > MULT $vreg_acc0, $vreg_gpr0, $vreg_gpr1 > > MULT $v...