search for: ahatanak

----- 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 Mar 26, 2013, at...

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 >> >> >...

...gt; v2i16 (or v4i8) and i32 is legal. > > To work around this problem, I can put back CodeGenFunction::EmitMipsBuiltinExpr > which was removed in r159368 and add code to do type conversions, but I prefer > not to do this. > > > On Mon, Jul 2, 2012 at 5:40 PM, Akira Hatanaka <ahatanak at gmail.com > <mailto:ahatanak at gmail.com>> wrote: > > Type::canLoslesslyBitCastTo(Type *Ty) in lib/VMCore/Type.cpp always returns > false when it checks whether an integer can be bitcast to a vector or vice > versa. > > For example, (i32 => v2i16...

...t; > > To work around this problem, I can put back > CodeGenFunction::EmitMipsBuiltinExpr > > which was removed in r159368 and add code to do type conversions, but I > prefer > > not to do this. > > > > > > On Mon, Jul 2, 2012 at 5:40 PM, Akira Hatanaka <ahatanak at gmail.com > > <mailto:ahatanak at gmail.com>> wrote: > > > > Type::canLoslesslyBitCastTo(Type *Ty) in lib/VMCore/Type.cpp always > returns > > false when it checks whether an integer can be bitcast to a vector > or vice > > versa. > &gt...

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 mem operand if...

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 clearing mem opera...

We already sort of model fast math flags at per-function level by resetting TargetOptions before selection dag is run. My proposal just makes changes that are needed to parallelize the backend (sorry about the misleading title of this thread). If modeling the flags at per-instruction level is the right thing to do, I agree that I shouldn't proceed with my current plan. I think exposing fp

...#39;m not sure that a function attribute is the best way to describe this. I'm open to being convinced it is, but I'd like to hear a bit more about the use case and get broader visibility on the proposal first. Philip On 09/16/2015 07:27 PM, Akira Hatanaka via llvm-commits wrote: > ahatanak created this revision. > ahatanak added a subscriber: llvm-commits. > > This patch adds support for a new IR function attribute "notail". The attribute is used to disable tail call optimization on calls to functions marked with the attribute. > > This attribute is different...

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 are generated...

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/attachment.html&...

> On Nov 19, 2014, at 4:52 PM, Eric Christopher <echristo at gmail.com> wrote: > > > > On Wed Nov 19 2014 at 4:39:42 PM Akira Hatanaka <ahatanak at gmail.com <mailto:ahatanak at gmail.com>> wrote: > On Wed, Nov 19, 2014 at 3:28 PM, Eric Christopher <echristo at gmail.com <mailto:echristo at gmail.com>> wrote: > So my general concern here is that lots of command line options that don't need to be or shouldn'...

...g IR level options? Seems to make sense from that > perspective and then they can add the appropriate attributes to the > functions themselves. (-mlongcalls for the long calls option for example). > > Thanks! > > -eric > > On Tue Nov 18 2014 at 12:26:49 PM Akira Hatanaka <ahatanak at gmail.com> > wrote: > >> Updated patch is attached. Note this is just a work-in-progress patch and >> I plan to address the feedback comments later if this patch is in the right >> direction. >> >> This is how the command line options are parsed and used by...

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 $vreg_acc1, $vr...

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 are generated during register allocation and expanded post-RA but before the final stack size is known. I use register scavenger to search for a temporary

See ARMCallingConv.td:113. The alignment of the arg is checked and if it's 8-byte aligned, the proper registers are chosen. deep On Tue, Aug 7, 2012 at 1:20 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Yes, I see the load is 8-byte aligned in the bit code. > > My question was, assuming that arguments requiring double word alignment > have to be passed in even/odd registers, how does the backend know that %0 > has to be passed in register r2 and r3? > &g...

...ests is failing, and I was wondering whether this could be a bug in arm-specific part of clang. The attached files are the tests (reduced test case) I used. On Mon, Aug 6, 2012 at 5:52 PM, Bill Wendling <wendling at apple.com> wrote: > > On Aug 6, 2012, at 3:21 PM, Akira Hatanaka <ahatanak at gmail.com> wrote: > > > When I compile this program > > > > $ cat vararg1-main.c > > > > typedef struct { > > double d; > > } S0; > > > > S0 g1; > > > > void foo0(int a, ...); > > > > int main(int argc, char **...

...e verifier after delay slots are filled. MipsInstrInfo::AnalyzeBranch generates incorrect results after delay slots are filled. Also, it seems that code in MachineVerifier.cpp wasn't written with architectures that have delay slots in mind. On Wed, Apr 25, 2012 at 11:59 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > Hi Anton, > > I ran llc with -verify-coalescing. There were no error messages. > Then I added code in MipsPassConfig::addPreEmitPass() to prevent machine > verifier from running post delay -slot-filler, and ran llc again. Again, > there were no error mes...

...Olesen <stoklund at 2pi.dk>wrote: > > 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 >...

(forwarding to llvm-dev) ---------- Forwarded message ---------- From: Akira Hatanaka <ahatanak at gmail.com> Date: Fri, Aug 17, 2012 at 2:35 PM Subject: Re: [LLVMdev] MIPS & GP register To: Carl Norum <carl at lytro.com> Will something like this fix the problem? if (!Subtarget.isLinux()) { reserve GP and GP_64 } To improve code, we have stopped reserving GP as a dedicated...

On Mar 26, 2013, at 10:29 AM, Akira Hatanaka <ahatanak at gmail.com> wrote: > The size of general purpose integer registers for mips32 is 32-bit and accumulators are 64-bit registers consisting of 32-bit hi/lo register pairs. So you will need two instructions to copy two 32-bit GPR registers to a 64-bit accumulator register. If spilling to multi...