> On 19 Nov 2024, at 4:18 PM, Tamar Christina wrote:
>
> External email: Use caution opening links or attachments
>
>
>> -Original Message-
>> From: Andrew Pinski
>> Sent: Friday, November 15, 2024 7:16 PM
>> To: Tamar Christina
>> Cc: gcc-patches@gcc.gnu.org; nd ; Richard Earnshaw
I am pleased to announce that the GCC Steering Committee has appointed
Alex Coplan as a maintainer for the AArch64 load / store pair fusion
pass.
In addition the steering committee has also appointed him as
maintainer for the Pair Fusion pass in the target independent
portions.
Please join me in
On Fri, Oct 4, 2024 at 9:25 PM Andre Vieira (lists)
wrote:
>
> Hi,
>
> The patch for 'arm: Fix missed CE optimization for armv8.1-m.main [PR
> 116444]' introduced regressions with arm targets that used 'noce' before.
> This is because it would approve all noce optimisations without using
> the def
On Fri, Sep 27, 2024 at 2:11 PM Andre Vieira (lists)
wrote:
>
>
>
> On 26/09/2024 18:56, Ramana Radhakrishnan wrote:
> >
>
> >> +/* Helper function to determine whether SEQ represents a sequence of
> >> + instructions representing the Ar
On Mon, Mar 4, 2024 at 1:43 PM Fangrui Song wrote:
>
> From: Fangrui Song
>
> -fno-pic -mfdpic generated code is like regular -fno-pic, not suitable
> for FDPIC (absolute addressing for symbol references and no function
> descriptor). The sh port simply upgrades -fno-pic to -fpie by setting
> fl
> On 25 Sep 2024, at 7:38 PM, Andre Vieira (lists)
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Hi,
>
> This patch restores missed optimizations for armv8.1-m.main targets that
> were missed when the generation of csinc, csinv and csneg were enabled
> or the sa
On Thu, Sep 12, 2024 at 8:42 PM Richard Earnshaw wrote:
>
> This short patch series adds the ability to unset the -mcpu and -march
> options on the Arm port. This helps to avoid ambiguities and warnings
> if, for some reason, the compiler flags need to be overridden.
>
> The main intent of this i
On Thu, Sep 5, 2024 at 4:30 PM Victor Do Nascimento
wrote:
>
>
> Changes from previous revision:
>
> As was done for the equivalent aarch64 patch, we rework this patch to do away
> with
> mission creep, keeping changes as simple as possible.
>
> We thus remove the `gimple_fold_builtin' changes th
I am pleased to announce that the GCC Steering Committee has appointed
Christophe Lyon as a MVE Reviewer for the AArch32 port.
Please join me in congratulating Christophe on his new role.
Christophe, please update your listings in the MAINTAINERS file.
Regards,
Ramana
> On 9 Sep 2024, at 10:34 PM, Andi Kleen wrote:
>
> External email: Use caution opening links or attachments
>
>
> Andi Kleen writes:
>
> Ping^4
>
> Could someone please approve this (nearly trivial) patch?
>
> Thanks,
> -Andi
>
>> Andi Kleen writes:
>>
>> Ping^3
>>
>>> Andi Kleen wr
> On 6 Aug 2024, at 4:14 PM, Richard Sandiford
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> Kyrylo Tkachov writes:
>>> On 5 Aug 2024, at 18:00, Richard Sandiford
>>> wrote:
>>>
>>> External email: Use caution opening links or attachments
>>>
>>>
>>> Kyryl
https://gcc.gnu.org/g:17d0982f425dbdeb528b70d141e70b006f6b9df6
commit r15-1423-g17d0982f425dbdeb528b70d141e70b006f6b9df6
Author: Ramana Radhakrishnan
Date: Wed Jun 19 06:48:57 2024 +0530
[MAINTAINERS] Update my email address and move to DCO.
Signed-off-by: Ramana Radhakrishnan
As $Subject.
Pushed.
Ramana
commit 01691a6d0582a921bbcc09ab5e0cd9e7deca2cca
Author: Ramana Radhakrishnan
Date: Tue Jun 18 16:05:31 2024 +0530
[MAINTAINERS] Update my email address and move to DCO.
Signed-off-by: Ramana Radhakrishnan
* MAINTAINERS: Update
On Sat, Dec 16, 2023 at 6:18 AM Andrew Carlotti wrote:
>
> This adds initial support for function multiversioning on aarch64 using
> the target_version and target_clones attributes. This loosely follows
> the Beta specification in the ACLE [1], although with some differences
> that still need to
> On 5 Oct 2023, at 14:04, Victor Do Nascimento
> wrote:
>
> External email: Use caution opening links or attachments
>
>
> On 10/5/23 12:42, Richard Earnshaw wrote:
>>
>>
>> On 03/10/2023 16:18, Victor Do Nascimento wrote:
>>> This patch adds the `aarch64-sys-regs.def' file to GCC, teachi
+ linaro-toolchain as I don't understand the CI issues on patchwork.
On Wed, Sep 27, 2023 at 8:40 PM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> > Hope this helps.
>
> Yes definitely!
>
> >> Passes regress/bootstrap, OK for commit?
> >
> > Target ? armhf ? --with-arch , -with-fpu , -with-float param
+ linaro-toolchain as I don't understand the CI issues on patchwork.
On Wed, Sep 27, 2023 at 8:40 PM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> > Hope this helps.
>
> Yes definitely!
>
> >> Passes regress/bootstrap, OK for commit?
> >
> > Target ? armhf ? --with-arch , -with-fpu , -with-float param
On Wed, Sep 27, 2023 at 1:51 AM Tamar Christina wrote:
>
> Hi All,
>
> Following the Neoverse N/V and Cortex-A optimization guides SIMD 0 immediates
> should be created with a movi of 0.
>
> At the moment we generate an `fmov .., xzr` which is slower and requires a
> GP -> FP transfer.
>
> Bootstr
n_logic , simd, 4] mov\t%0., %1.
> + [?r , w ; multiple , * , 8] #
> + [?w , r ; multiple , * , 8] #
> + [?r , r ; multiple , * , 8] #
> + [w , Dn; neon_move , simd, 4] <<
> aarch64_output_simd_mov_immediate (ope
Reviewed-by: Ramana Radhakrishnan
A very initial review here . I think it largely looks ok based on the
description but I've spotted a few obvious nits and things that come
to mind on reviewing this. I've not done a very deep review but hope
it helps you move forward. I'm happy t
Hi Wilco,
Thanks for your email.
On Tue, Sep 26, 2023 at 12:07 AM Wilco Dijkstra wrote:
>
> Hi Ramana,
>
> >> __sync_val_compare_and_swap may be used on 128-bit types and either calls
> >> the
> >> outline atomic code or uses an inline loop. On AArch64 LDXP is only
> >> atomic if
> >> the val
e went with LDXP in this form.
Has something changed from then ?
Reviewed-by : Ramana Radhakrishnan
regards
Ramana
>
> Passes regress/bootstrap, OK for commit?
>
> gcc/ChangeLog/
> PR target/111404
> * config/aarch64/aarch64.cc (aarch64_split_compare_and_swa
On Wed, Jul 19, 2023 at 5:44 PM Andrew Carlotti via Gcc-patches
wrote:
>
> Updated patch to fix the fp16 intrinsic pragmas, and pushed to master.
> OK to backport to GCC 13?
>
>
> Many intrinsics currently depend on both an architecture version and a
> feature, despite the corresponding instructio
be in gcc/config/arm but its possibly ok given the usage
statistics.
Reviewed-by: Ramana Radhakrishnan.
regards
Ramana
>
> --
> Evandro Menezes
>
>
>
> gcc/ChangeLog:
>
> * config/a
On Fri, Jan 27, 2023 at 2:44 PM Andrea Corallo via Gcc-patches
wrote:
>
> gcc/
>
> * config/arm/arm.cc (arm_valid_target_attribute_rec): Add ARM function
> attribute 'branch-protection' and parse its options.
> * doc/extend.texi: Document ARM Function attribute
> 'branch-p
Ping x 2
Ramana
On Thu, 17 Nov 2022, 20:15 Ramana Radhakrishnan,
wrote:
> On Fri, Nov 11, 2022 at 9:50 PM Ramana Radhakrishnan
> wrote:
> >
> > On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
> > wrote:
> > >
> > > On Thu, Nov 10, 202
o the tree later this week after having built armhf and
a bootstrap and test run on aarch64-linux-gnu.
Thanks,
Ramana
commit 7dd15fae0ac1455f5818a1fc0078e35d85e1e250
Author: Ramana Radhakrishnan
Date: Wed Nov 16 10:32:04 2022 +
[Patch Arm] Add neon_fcadd and neon_fcmla to is
On Fri, Nov 18, 2022 at 4:59 PM Kyrylo Tkachov via Gcc-patches
wrote:
>
>
>
> > -Original Message-
> > From: Andrea Corallo
> > Sent: Thursday, November 17, 2022 4:38 PM
> > To: gcc-patches@gcc.gnu.org
> > Cc: Kyrylo Tkachov ; Richard Earnshaw
> > ; Stam Markianos-Wright > wri...@arm.com
On Fri, Nov 18, 2022 at 9:33 AM Srinath Parvathaneni
wrote:
>
> Hi,
>
> > -Original Message-
> > From: Ramana Radhakrishnan
> > Sent: Thursday, November 17, 2022 8:27 PM
> > To: Srinath Parvathaneni
> > Cc: gcc-patches@gcc.gnu.org; Richard Earnsha
On Mon, Oct 24, 2022 at 9:55 AM Eric Botcazou via Gcc-patches
wrote:
>
> Hi,
>
> until most other machine attributes, this one does not work in Ada because,
> while it applies to pointer-to-function types, it is explicitly marked as
> requiring declarations in the implementation.
>
> Now, in Ada,
On Thu, Nov 17, 2022 at 5:30 PM Richard Sandiford via Gcc-patches
wrote:
>
> Wilco Dijkstra writes:
> > Hi Richard,
> >
> >> Can you go into more detail about:
> >>
> >>Use :option:`-mdirect-extern-access` either in shared libraries or in
> >>executables, but not in both. Protected symbo
On Thu, Nov 10, 2022 at 10:38 AM Srinath Parvathaneni via Gcc-patches
wrote:
>
> Hi,
>
> This patch adds support for Arm frame unwinding instruction "0xb5" [1]. When
> an exception is taken and "0xb5" instruction is encounter during runtime
> stack-unwinding, we use effective vsp as modifier in po
On Fri, Nov 11, 2022 at 9:50 PM Ramana Radhakrishnan
wrote:
>
> On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
> wrote:
> >
> > On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
> > wrote:
> > >
> > >
> > >
> > &
>
> OK with the comment typos fixed.
>
> > > > gcc/ChangeLog:
> > > >
> > > > 2018-11-11 Tamar Christina
> > > >
> > > > * config/aarch64/aarch64-simd.md (aarch64_fcadd,
> > > > fcadd3, aarch64_fcmla,
> > > > fcmla4): New.
> > > > * config/aarch64/aarch64.h (TAR
On Thu, Nov 10, 2022 at 7:46 PM Ramana Radhakrishnan
wrote:
>
> On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
> wrote:
> >
> >
> >
> > On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote:
> > >
> > >
> > > On 08/11/2022 18:20
On Thu, Nov 10, 2022 at 10:24 AM Srinath Parvathaneni via Gcc-patches
wrote:
>
> Hi,
>
> This patch adds the -mcpu support for the Arm Cortex-X1C CPU.
>
> Regression tested on arm-none-eabi and bootstrapped on
> arm-none-linux-gnueabihf.
>
> Ok for GCC master?
Ok
Ramana
>
> Regards,
> Srinath.
On Thu, Nov 10, 2022 at 6:03 PM Richard Earnshaw
wrote:
>
>
>
> On 10/11/2022 17:21, Richard Earnshaw via Gcc-patches wrote:
> >
> >
> > On 08/11/2022 18:20, Ramana Radhakrishnan via Gcc-patches wrote:
> >> PR92999 is a case where the VFP calling conv
while I fix my environment ?
gcc/ChangeLog:
PR target/92999
* config/arm/arm.c (aapcs_vfp_allocate_return_reg): Adjust to handle
aggregates with elements smaller than SFmode.
gcc/testsuite/ChangeLog:
* gcc.target/arm/pr92999.c: New test.
Thanks,
Ramana
Signed-off-by: Ramana Radhakrishnan
Update affiliation as I'm moving on from Arm. More from me in a month or so.
Pushed to trunk
regards
Ramana
commit 4e5f373406ed5da42c4a7c4b7f650d92195f2984
Author: Ramana Radhakrishnan
Date: Fri Nov 4 09:30:00 2022 +
Update affiliation
diff --git a/htdocs/steering.html b/h
Nick Clifton
arm port Richard Earnshaw
-arm port Ramana Radhakrishnan
+arm port Ramana Radhakrishnan
arm port Kyrylo Tkachov
avr port Denis Chertykov
bfin port Jie
Hi Lance,
Thanks for your contribution - looks like your first one to GCC ?
The patch looks good to me, though it should probably go through a
full test suite run on arm-linux-gnueabihf and get a ChangeLog - see
here for more https://gcc.gnu.org/contribute.html#patches.
This is probably small en
> I think the main outstanding thing is the question of support here. I'd love
> for a few more folks to weigh in, tagging a few folks who may have ideas:
> @tqchen @jroesch @kparzysz-quic @u99127 @Mousius @leandron @comaniac @zhiics
> @Hzfengsy @ZihengJiang @yzhliu @masahi @icemelon
>
> broadl
> I think the main outstanding thing is the question of support here. I'd love
> for a few more folks to weigh in, tagging a few folks who may have ideas:
> @tqchen @jroesch @kparzysz-quic @u99127 @Mousius @leandron @comaniac @zhiics
> @Hzfengsy @ZihengJiang @yzhliu @masahi @icemelon
>
> broadl
@driazati - this is a really good starting point for releases and I'm very
glad this is coming together.
I had a ponder last night.
A few additional points to consider for an enhancement to this RFC or make it
clearer here in this RFC itself.
- Lifecycle of a release , what happens to a rel
2021 at 22:03
To: Qing Zhao
Cc: Ramana Radhakrishnan ,
linux-harden...@vger.kernel.org , kees Cook
, Keith Packard ,
thomas.preudho...@celest.fr ,
adhemerval.zane...@linaro.org , Richard
Sandiford , gcc-patches@gcc.gnu.org
Subject: Re: [PATCH v4 1/1] [ARM] Add support for TLS register based
Wirkus
Cc: Ramana Radhakrishnan ,
gcc-patches@gcc.gnu.org , Richard Earnshaw
Subject: Re: [PATCH][GCC] arm: add armv9-a architecture to -march
You can't make an omelette without breaking eggs, as they say. New
architectures need new assemblers.
However, I wonder if there's anything in
This is OK
Ramana
On 22/09/2021, 09:45, "Przemyslaw Wirkus" wrote:
Patch is adding Cortex-R52+ as 'cortex-r52plus' command line
flag for -mcpu option.
See: https://www.arm.com/products/silicon-ip-cpu/cortex-r/cortex-r52-plus
OK for master?
gcc/ChangeLog:
2021-09-22
How can we move this forward - this appears to be getting stalled ?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/22#issuecomment-920704274
Minor nit - the title of the RFC should really read - [RFC] Use CMSIS-NN with
TVM.
@manupa-arm , @Mousius ..
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm-rfcs/pull/15#issuecomment-892150107
> > I'd suggest that "nearly done" is ambiguous? As a less ambiguous
> > alternative I'd propose always opening a tracking issue (if the RFC is big
> > enough to require it) when you raise an RFC and if it ultimately gets
> > rejected we just close the issue? This also allows code to evolve alon
@areusch - could this also get a new ci-cpu image ?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/7628#issuecomment-808152945
@mbaret - could you please review this ? And once this is approved we need to
request @tqchen or @tmoreau89 to respin docker.ci_cpu images.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/tvm/pull/
I think @dmitriy-arm has been looking into this.
---
[Visit
Topic](https://discuss.tvm.apache.org/t/model-graph-size-doubling-after-partitioning-for-arm-compute-library/9131/4)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [cl
I would like to see some thought about release process and release timelines
for the TVM project . Initially would like some indication of when 0.8 is
likely to happen and future releases are likely to happen.
Is Ansor now considered fully merged into the code base ?
regards
Ramana
--
On Thu, Oct 8, 2020 at 10:22 AM Jakub Jelinek via Gcc-patches
wrote:
>
> Hi!
>
> The arm target hook for divmod wasn't prepared to handle constants passed to
> the function.
>
> Fixed thusly, bootstrapped/regtested on armv7hl-linux-gnueabi, ok for trunk?
>
> 2020-10-08 Jakub Jelinek
>
>
Thanks for this initiative and it is commendable towards reducing the burden
for use of the Apache TVM project.
Could you link to the Apache policy here for other folks to read and see what
other guidelines need to be investigated as I couldn't find it easily enough ?
It might also be worthwh
@comaniac @lhutton1 - maybe you could help ?
---
[Visit
Topic](https://discuss.tvm.apache.org/t/codegenchost-and-codegencbase-and-relation-to-internal-and-external-compilers/7933/2)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails
I'd like to see the tvmc work to be functional before we cut the release
please. I'd also like to see the Ethos-N PRs land as well.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/apache/incubator-tvm/iss
-mcpu=neoverse-n1 should be fine depending on the version of llvm . I can't
remember if you need anything in the -mattr to specifically allow for the dot
product or fp16 .
@giuseros has probably some experience here
Ramana
---
[Visit
Topic](https://discuss.tvm.apache.org/t/llvm-targ
On Thu, Sep 3, 2020 at 6:13 PM Kees Cook via Gcc-patches
wrote:
>
> On Thu, Sep 03, 2020 at 09:29:54AM -0500, Qing Zhao wrote:
> > On average, all the options starting with “used_…” (i.e, only the
> > registers that are used in the routine will be zeroed) have very low
> > runtime overheads, at
On Wed, Aug 26, 2020 at 12:08 PM Richard Biener via Gcc-patches
wrote:
>
> On Tue, Aug 25, 2020 at 6:32 PM Maciej W. Rozycki wrote:
> >
> > Hi Kito,
> >
> > > I just found the mail thread about div mod with -fnon-call-exceptions,
> > > I think keeping the default LIB2_DIVMOD_EXCEPTION_FLAGS uncha
I believe using this needs cmake 3.12 or later because of the use of
FindPython3 in your cmake modules and this would require an update to the
install source documentation as that implies a requirement of cmake > 3.5 for
building tvm.
---
[Visit Topic](https://discuss.tvm.ai/t/add-the-do
On Mon, Aug 24, 2020 at 4:35 PM Christophe Lyon
wrote:
>
> On Mon, 24 Aug 2020 at 11:09, Christophe Lyon
> wrote:
> >
> > On Sat, 22 Aug 2020 at 00:44, Ramana Radhakrishnan
> > wrote:
> > >
> > > On Wed, Aug 19, 2020 at 10:32 AM
On Fri, Aug 21, 2020 at 2:28 PM Joe Ramsay wrote:
>
> From: Joe Ramsay
>
> Hi,
>
> Previously, the machine description patterns for vst1q accepted a generic
> memory
> operand for the destination, which could lead to an unrecognised builtin when
> expanding vst1q* intrinsics. This change fixes t
On Wed, Aug 19, 2020 at 10:32 AM Christophe Lyon via Gcc-patches
wrote:
>
> armv8-m.base (cortex-m23) has the movt instruction, so we need to
> disable the define_split to generate a constant in this case,
> otherwise we get incorrect insn constraints as described in PR94538.
>
> We also need to f
On Mon, Aug 17, 2020 at 7:42 PM Dennis Zhang wrote:
>
>
> Hi all,
>
> This patch enables MVE vsub instructions for auto-vectorization.
> It adds RTL templates for MVE vsub instructions using 'minus' instead of
> unspec expression to make the instructions recognizable for vectorization.
> MVE targe
On Thu, Aug 20, 2020 at 3:31 PM Joe Ramsay wrote:
>
> Hi Ramana,
>
> Thanks for the review.
>
> On 18/08/2020, 18:37, "Ramana Radhakrishnan"
> wrote:
>
> On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote:
> >
> > From: Joe Ramsay
&g
On Thu, Aug 13, 2020 at 2:18 PM Joe Ramsay wrote:
>
> From: Joe Ramsay
>
> Hi,
>
> Previously, the machine description patterns for vst1q accepted a generic
> memory
> operand for the destination, which could lead to an unrecognised builtin when
> expanding vst1q* intrinsics. This change fixes t
Thanks that sounds like it should be relatively straightforward to integrate.
Ramana
---
[Visit
Topic](https://discuss.tvm.ai/t/per-axis-quantization-support-for-tflite/6726/4)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [c
Hello there,
Welcome to the community ! AFAIK, there is nothing in place for signed int8
symmetric quantization support in the tflite frontend yet even in master :
however I believe the underlying codegeneration framework can support it with
the qnn dialect of relay based on this
https://di
On Mon, Jun 1, 2020 at 10:45 PM Vineet Gupta via Libc-alpha
wrote:
>
> On 6/1/20 9:38 AM, Adhemerval Zanella via Libc-alpha wrote:
> >
> >
> > On 29/05/2020 23:00, Vineet Gupta wrote:
> >> Signed-off-by: Vineet Gupta
> >
> > LGTM, some comments below.
> >
> >> -#include
> >> -#include
> >> -
>
On Mon, Apr 27, 2020 at 2:22 PM Andre Vieira (lists)
wrote:
>
> Hi,
>
> The code change that caused this regression was not meant to affect neon
> code-gen, however I missed the REG fall through. This patch makes sure
> we only get the left-hand of the PLUS if it is indeed a PLUS expr.
>
> I sugg
On Fri, May 15, 2020 at 12:31 PM Srinath Parvathaneni
wrote:
>
> Armv8.1-M Mainline Security Extensions related changes in GCC-10.
>
>
> ### Attachment also inlined for ease of reply
> ###
>
>
> diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
>
On Fri, May 15, 2020 at 7:36 AM Christophe Lyon
wrote:
>
> On Thu, 14 May 2020 at 17:58, Ramana Radhakrishnan
> wrote:
> >
> > > static bool reg_needs_saving_p (unsigned reg)
> > > {
> > >unsigned long func_type = arm_current_func_type ();
> &g
> static bool reg_needs_saving_p (unsigned reg)
> {
>unsigned long func_type = arm_current_func_type ();
Ah ok , you needed it here.
Ramana
On Thu, May 14, 2020 at 3:58 PM Christophe Lyon via Gcc-patches
wrote:
>
> The same code pattern occurs in several functions, so it seems cleaner
> to move it into a dedicated function.
>
> 2020-05-14 Christophe Lyon
>
> gcc/
> * config/arm/arm.c (reg_needs_saving_p): New functi
On Thu, May 14, 2020 at 3:57 PM Christophe Lyon via Gcc-patches
wrote:
>
> While running the tests with -march=armv5t -mthumb, I came across this
> error message which I think could be clearer.
>
> 2020-05-14 Christophe Lyon
>
> gcc/
> * config/arm/arm.c (thumb1_expand_prologue)
This is a draft PR and only for discussion but not for merging as is.
These are a couple of commits that show a proof of concept about how we could
restructure and improve the tflite frontend. I've lightly tested these by
compiling a couple of tflite models to give me some confidence that they w
Any more opinions ?
Ramana
---
[Visit
Topic](https://discuss.tvm.ai/t/rfc-improve-pull-requests-with-respect-to-bug-fixes/6529/4)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tvm.ai/email/unsub
clang-tidy certainly looks interesting as well as something deeper than
clang-format and that is likely to help us with other aspects that we may be
missing. However I'm probably a bit old-school and would probably be a bit more
careful about clang-tidy -fix ... :)
That might be the next ste
Maybe take the next steps ?
1. Do a flag day clang-format rewrite and take the one time cost for every
patch having a merge conflict ?
2. Once we are clang-format clean, we could have CI run clang-format and fail
CI instantly if there is any change in the source base compared to the pull
r
On Wed, Apr 29, 2020 at 4:19 PM Christophe Lyon via Gcc-patches
wrote:
>
> Remove two duplicate entries in isr_attribute_args ("abort" and
> "ABORT").
>
> 2020-04-29 Christophe Lyon
>
> PR target/57002
> gcc/
> * config/arm/arm.c (isr_attribute_args): Remove duplicate en
On Wed, Apr 29, 2020 at 11:30 AM Richard Sandiford
wrote:
>
> Essentially the same fix as for x86.
>
> Tested on arm-linux-gnueabihf and armeb-eabi. Bordering on the obvious
> I guess, but OK to install?
>
> Richard
>
Ok.
Ramana
>
> 2020-04-29 Richard Sandiford
>
> gcc/
> * config/a
@matt-arm : you may find this interesting.
---
[Visit
Topic](https://discuss.tvm.ai/t/byoc-problem-about-subgraph-with-tupletypenode-inputs/6522/3)
to respond.
You are receiving this because you enabled mailing list mode.
To unsubscribe from these emails, [click
here](https://discuss.tv
**Motivation**
We would like to move towards a world where there is a clear attempt to try and
start becoming more predictable with release cycles and what the usage of a
release is going to be . As part of this ,releases need regression fixes.
However, if the community is making releases, th
On Wed, Apr 22, 2020 at 8:25 PM Joel Jones wrote:
>
> Yes, Bellsoft's contribution is to be covered under the Marvell copyright
>
> assignment, as this is a work for hire.
Thanks !
Ramana
>
>
>
> Joel
>
>
>
> >Yes, Bellsoft's contribution is to be covered under the Marvell copyright
>
> >assign
>
>
> > It would be great if we can avoid the hack into the `with_same_user`. One
> > alternative would be still pass in the `PYTEST_ADDOPTS` env variable from
> > the docker env(for development purposes) but source the setup-pytest-env
> > within each of the script.
> > This also makes the in
>
>
Thanks for the quick review.
> It would be great if we can avoid the hack into the `with_same_user`. One
> alternative would be still pass in the `PYTEST_ADDOPTS` env variable from the
> docker env(for development purposes) but source the setup-pytest-env within
> each of the script.
>
I don't like my current hack of overloading "with_same_user" for sourcing this
global environment but it seemed like the simplest hack and worked in my
environment. Obviously I don't have cuda testing in my CI or my regular test
environment, so this isn't fully clear.
--
You are receiving this
In many places having a global pytest flag is useful . For me with the
build and test of tvm , I would like to be able to globally pass in
pytest options as part of development flow or CI flows where one would
like to measure other things regularly that need measurements including
pytest coverage d
On Wed, Apr 22, 2020 at 5:38 AM Joel Jones via Gcc-patches
wrote:
>
> I just joined the gcc-patches list, so I hope the mail software can parse
> this out with an "In-Reply-To" header.
>
> I work for Marvell, and Anton's work is approved for submittal. I wrote the
> first version of the .md file
To move this forward, I spent some time over the past few days to get both
TF1.15 and TF2.x testing with our CI and ran into a few issues.
See
https://github.com/apache/incubator-tvm/pull/5392
https://github.com/apache/incubator-tvm/pull/5391
regards
Ramana
---
[Visit
Topic](https:/
@jknight - In case it wasn't obvious I do support the initiative.
Yes, the scheme you have outlined works (and seems to work) reasonably well for
information dissemenination about new features.
When there are interactive discussions in that fashion and design changes made
due to the discussio
My motivation was indeed for peer collaboration or interactive peer
conversations and an additional use of existing tools in the toolbox.
regards
Ramana
---
[Visit Topic](https://discuss.tvm.ai/t/tvm-online-meetups/6382/4) to respond.
You are receiving this because you enabled mailing lis
I think this is a good initiative. However it is quite expensive in terms of
logistics and organization.
Additionally it's probably time to think about using the slack channels more
and ensuring that conversations on slack move to the discuss forums or the PRs
once the interactive conversati
I wasn't proposing that as a solution, that is one of the options. I'm merely
stating that this is still a problem that will hit others most notably anyone
using the C backend .
Ramana
---
[Visit
Topic](https://discuss.tvm.ai/t/discuss-module-based-model-runtime-interface/5025/61)
to r
So, the problem hasn't been fixed : there is a "solution" depending on the
presence of an llvm target.
Ramana
---
[Visit
Topic](https://discuss.tvm.ai/t/discuss-module-based-model-runtime-interface/5025/59)
to respond.
You are receiving this because you enabled mailing list mode.
To un
This won't work by default for the C backend where we don't necessarily rely on
the presence of llvm or are we saying that there needs to be an llvm solution
for the backend just to produce this constant data object always, so we do need
a general solution
Ramana
---
[Visit
Topic]
I would start with incorporating these points in the "Development Process" bits
in the TVM documentation. Will put up a pull request since no one has commented
on this in about 2 months.
Ramana
---
[Visit
Topic](https://discuss.tvm.ai/t/development-process-and-backporting-patches-to-rele
In my experience plain loop unrolling has always been a blunt hammer and is not
useful in the general case, thus turning that off by default in LLVM makes
sense. Targeted unrolling with vectorization and other loop optimizations is
more beneficial .
I hadn't realized that LLVM turned on plai
1 - 100 of 1894 matches
Mail list logo
