sgundapa closed this revision.
sgundapa added a comment.
I forgot to update the Differential Revision in the commit.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D68401/new/
https://reviews.llvm.org/D68401
___
cfe-co
sgundapa created this revision.
sgundapa added reviewers: bcain, bcahoon.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
Before this patch if we pass "-mcpu=hexagonv65 -march=hexagon" in this order,
the driver fails to figure out the correct cpu version. This patch fixed th
sgundapa abandoned this revision.
sgundapa added a comment.
This patch is already merged in a different commit
Repository:
rL LLVM
https://reviews.llvm.org/D39071
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-b
sgundapa created this revision.
Repository:
rL LLVM
https://reviews.llvm.org/D39071
Files:
lib/Driver/ToolChains/Hexagon.cpp
Index: lib/Driver/ToolChains/Hexagon.cpp
===
--- lib/Driver/ToolChains/Hexagon.cpp
+++ lib/Driver/Too
This revision was automatically updated to reflect the committed changes.
Closed by commit rL316102: [Hexagon] Handling of new HVX flags and
target-features (authored by sgundapa).
Changed prior to commit:
https://reviews.llvm.org/D38852?vs=118802&id=119507#toc
Repository:
rL LLVM
https://r
sgundapa added a comment.
Ping
Repository:
rL LLVM
https://reviews.llvm.org/D38852
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
sgundapa created this revision.
Herald added a subscriber: eraman.
This patch has the following changes
1. A new flag "-mhvx-length={64B|128B}" is introduced to specify the
length of the vector. Previously we have used "-mhvx-double" for 128 Bytes.
This adds the target-feature "+hvx-length{64|12
This revision was automatically updated to reflect the committed changes.
Closed by commit rL314926: [Hexagon] Move getHexagonTargetFeatures to
Hexagon.cpp (NFC) (authored by sgundapa).
Changed prior to commit:
https://reviews.llvm.org/D38548?vs=117686&id=117709#toc
Repository:
rL LLVM
http
sgundapa added a comment.
The only change that is needed is to disable lookup-tables based on the
attribute "no-jump-tables" set by "-fno-jump-tables" clang flag.
It implies that this change is not required.
https://reviews.llvm.org/D35577
___
cf
sgundapa abandoned this revision.
sgundapa added a comment.
Refer to https://reviews.llvm.org/D35577 as we decided to disable lookup tables
under -fno-jump-tables
https://reviews.llvm.org/D35578
___
cfe-commits mailing list
cfe-commits@lists.llvm.o
sgundapa added a comment.
Thanks. I will make change to this affect
https://reviews.llvm.org/D35577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
sgundapa added a comment.
I am waiting for others to approve/review the decision.
https://reviews.llvm.org/D35577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
sgundapa added a comment.
If it is okay for the reviewers, I have no problem using -fno-jump-tables to
this effect.
I need to update https://reviews.llvm.org/D35578 and
https://reviews.llvm.org/D35579
https://reviews.llvm.org/D35577
___
cfe-commit
sgundapa added a comment.
> "Should this just be part of the tuning for the hexagon backend and not
> options at all"
This will be useful to all the backends/archs that support a tightly coupled
memory.
AFAIK, hexagon is not the only target that has a TCM.
https://reviews.llvm.org/D35577
_
sgundapa added a comment.
This is not going to be a temporary option
https://reviews.llvm.org/D35577
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
sgundapa added a comment.
The discussion is scattered across these patches
https://reviews.llvm.org/D35578 and https://reviews.llvm.org/D35579.
I will provide a brief summary here:
The idea is to control the generation of data (lookup table) generated from a
function, specifically when the user
sgundapa added a comment.
> Moreover, why can't this determining factor be built into the compiler so the
> user doesn't even have to bother. That would be a more ideal user experience.
Here is a use case : For the code that stays in TCM, the customer doesn't want
the data that the code refers
sgundapa added a comment.
> Wouldn't the fix be to make the backend deal with this, then? Either by
> putting the table with the function text, or or opting out of lookup tables?
> It seems that might be a better experience for the user.
That is perfectly reasonable and in fact i have committe
sgundapa updated this revision to Diff 107317.
sgundapa added a comment.
Made the changes asked by reviewers
https://reviews.llvm.org/D35577
Files:
include/clang/Driver/Options.td
include/clang/Frontend/CodeGenOptions.def
lib/CodeGen/CodeGenFunction.cpp
lib/Driver/ToolChains/Clang.cpp
sgundapa added a comment.
I will try to address the concerns here:
> What exactly is the motivation? I'm trying to narrow down the justification
> for adding yet more flags.
(I just typed this message in https://reviews.llvm.org/D35579)
For backends with "tightly coupled memory", in scenarios w
sgundapa added a comment.
The switch-case statements generate two kinds of tables.
1. Jump tables
2. Lookup tables.
While the general assumption is that switch-case statements generate jump
tables, the below case generates a lookup table by late simplifycfg
int foo(int x) {
switch (x) {
c
21 matches
Mail list logo
