similar to: Code owner for Hexagon backend

Chris, I'd like to take code ownership of the Hexagon backend. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On Nov 15, 2012, at 11:10 AM, Anshuman Dasgupta <adasgupt at codeaurora.org> wrote: > Chris, > > I'd like to take code ownership of the Hexagon backend. Sounds fine to me, assuming your other colleagues are ok with that. -Chris

I wanted to give everybody a heads-up on upcoming commits for the Hexagon backend. We will be removing support for older versions of the Hexagon architecture - specifically Hexagon-v2 and Hexagon-v3. These are no longer being used by compiler users. Matthew Curtis has committed the first clang patch to remove driver support for these versions. There will be follow-up patches on the LLVM side

On 03/14/2013 12:51 PM, Anshuman Dasgupta wrote: > I wanted to give everybody a heads-up on upcoming commits for the > Hexagon backend. We will be removing support for older versions of the > Hexagon architecture - specifically Hexagon-v2 and Hexagon-v3. These are > no longer being used by compiler users. Matthew Curtis has committed the > first clang patch to remove driver support

Hi Anshu, no, I did not fill a bug report. It is not so easy to make the code fail noticeably; during Hexagon CodeGen tests it happens silently and tests pass. I am working on another VLIW backend which uses DFAPacketizer and compiling llvm with gcc-4.4 makes it segfault, but with gcc-4.7 the bug gets hidden again (it still happens, but values after DFAStateEntryTable in memory are such that

Hi Anshu, I don't have commit access. It applies correctly on trunk, I've just checked it. Could you please commit it? Ivan On 26/06/2012 04:44, adasgupt at codeaurora.org wrote: > Hi Ivan, > > Sorry, I should have been more explicit in my last email. The patch looks > good to me. Please check that it applies on trunk and go ahead and commit. > > Thanks > -Anshu

Hi Anshu, Thanks again for your feedbacks. On 24/08/2012 17:01, Anshuman Dasgupta wrote: > Hi Ivan, > >> I missed last 2 commits made by Alexey. Following his advices, I >> updated the patch. It should be ok now. >> Thanks Anshu! >> >> I've recently added more functional units to our Schedule.td and the >> generation time became painfully long. In

Hi Jonas, > It is interesting to find this in the ARM backend, considering your answer. The ARM backend doesn't use the DFA packetizer. It's only used by Hexagon. At this point, there is no plan to address thisin the DFA packetizer since none of the supported targets needthe functionality. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,

Hi Anshu, Just in case you have forgotten this thread ;-). Is this patch ok to commit or does it not apply to trunk properly ? I can fix it if that's the problem. Ivan On 20/06/2012 19:33, Anshuman Dasgupta wrote: > > > Thanks for reviewing this. I added a top comment for AddInsnClass > and I fixed the violation of column numbers. > > Great. Looks good to me. > >

Carlos, I committed a fix in r169783. Thanks for catching this. However, I could not reproduce an invalid read or a segfault even with fadd.ll. Is there a test case you can check in that reproduces this bug? Even if the segfault occurs intermittently, that's better than no test case at all. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by

Great! Can you please check in that test case or better still, a reduced version of that test. Thanks -Anshu --- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation On 12/11/2012 5:47 AM, Carlos Sánchez de La Lama wrote: > Hi again, > > I can confirm r169783 fixes the problem. My testbench segfaulted in > r169782 but works after your

Hi Anshu, I got a testbench which fails (and segfaults) consistently with an environment (gcc + os) conveniently preserved in a virtual machine. I will confirm that it is gone there and report. Thanks for the fix :) Carlos 2012/12/10 Anshuman Dasgupta <adasgupt at codeaurora.org> > Carlos, > > I committed a fix in r169783. Thanks for catching this. > > However, I could

Committed in r159281. -Anshu On 6/26/2012 3:04 AM, Ivan Llopard wrote: > Hi Anshu, > > I don't have commit access. It applies correctly on trunk, I've just > checked it. Could you please commit it? > > Ivan > > On 26/06/2012 04:44, adasgupt at codeaurora.org wrote: >> Hi Ivan, >> >> Sorry, I should have been more explicit in my last email. The

I missed last 2 commits made by Alexey. Following his advices, I updated the patch. It should be ok now. Ivan On 27/06/2012 21:42, Anshuman Dasgupta wrote: > Committed in r159281. > > -Anshu > > > On 6/26/2012 3:04 AM, Ivan Llopard wrote: >> Hi Anshu, >> >> I don't have commit access. It applies correctly on trunk, I've just >> checked it.

Hi Anshu, Thanks for reviewing this. I added a top comment for AddInsnClass and I fixed the violation of column numbers. On 15/06/2012 21:31, Anshuman Dasgupta wrote: > Hi Ivan, > > The patch looks good to me. I have a couple of minor comments: > > +void State::AddInsnClass(unsigned InsnClass, > Add a top level comment describing the function > > + std::map<State*,

On 28/08/2012 00:21, Anshuman Dasgupta wrote: > Ivan, > > Thanks for working on the patch. It looks good to me except for the > removal of the Transition class: > > > (1) Should I completely remove Transition and create a map structure > in State (input, state) to replace them? > > Yes, please remove the Transition class and create a map structure in > State

Ivan, Thanks for working on the patch. It looks good to me except for the removal of the Transition class: > (1) Should I completely remove Transition and create a map structure in State (input, state) to replace them? Yes, please remove the Transition class and create a map structure in State instead of TransitionSet. Thanks -Anshu On 8/25/2012 6:42 AM, Ivan Llopard wrote: > Hi

Hi Anshu, the "test case" I referred to requires the compilation of our whole back-end. It segdaults when using gcc-4.4.3 under Ubuntu 10.04, with other combinations I have tested it still happens (before your patch) but is not noticeable unless using gdb. I have tried making valgrind catch it but no success... so I guess the only way to *see* it is using the debugger. I remember

Hi Anshu, Would there be any interest in extending this algorithm to handling more extensive models, such as VLIW scheduling based on FU's and bundle space... ie handle multiple stages ? I might do it and commit, if there is acceptance and guidance... Jonas ________________________________ From: Anshuman Dasgupta [mailto:adasgupt at codeaurora.org] Sent: Tuesday, February 12, 2013 4:47 PM

There are a bunch of us working on LLVM in Austin. So we're organizing a LLVM Austin Social in September. The social will be on Wednesday, September 12 from 5 pm at the BB Rovers Cafe and Pub. It'll be great to meet up with folks in Austin who are also interested in LLVM. Please reply and let me know if you plan on attending so that I can get a count. BB Rovers is on Jollyville road